Bug 164454 – The GC should be optionally concurrent and disabled by default

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Filip Pizlo]

We're at the point where we can create an option to run the GC concurrently and make it default to false.

This bug will start with the patch of https://bugs.webkit.org/show_bug.cgi?id=163734; I may just dup that to this and land a combined patch.

[Filip Pizlo]

There are two things that definitely need to get done for this to be correct:

1) Separate the SlotVisitor used by the mutator's write barrier from the SlotVisitor used by the collector thread.  It's not super clear if the write barrier should even use a SlotVisitor, but whatever - the MarkStackArray probably has everything we need to efficiently transfer the entire contents of the mutator SlotVisitor into the collector SlotVisitor.

2) We need to stopAllocating/resumeAllocating.  It's tempting to think that this should be done by the mutator, but that's actually just complicating things.  It should be the collector's responsibility, and I think that these methods should be called from stopTheWorld/resumeTheWorld.

[Filip Pizlo]

Created attachment 294001 [details]
something

If I did everything right for the past year then this patch will basically just work.

[Filip Pizlo]

Created attachment 294004 [details]
it actually sort of did some things

It started a concurrent eden collection, then the fixpoint went off the rails and we bloated memory to 500MB.  Then it did another GC and crashed.

That's a pretty good start.

[Filip Pizlo]

Created attachment 294007 [details]
it sort of works

This patch is pretty broken, but it's doing concurrent collections in Octane/splay.  It crashes eventually of course.

[Filip Pizlo]

Here's a run of splay, until the point where it gets itself into an infinite loop because the GC corrupted the heap so bad.

The benchmark is modified to print the time it takes to run a tick.  That's what the lines like "0.8380413055419922 ms." say: they mean that a tick took 0.8380413055419922 ms.

When the GC does a stop-the-world increment, it uses its [GC: blah blah]" logging syntax.  A GC cycle will require multiple increments if concurrent GC is enabled.  Each GC increment reports how long it took.  The last increment also reports the total cycle time.  Between increments of an active GC cycle (so before something like [GC: 71418 kb => FullCollection, 0.037991 ms...] and something like [Increment: 72558 kb, 0.888023 ms, cycle 15.558143 ms]), the application and collector are running concurrently.

From the log, it's pretty clear that after the second collection, things go very badly wrong - on the third GC the collector thinks that the heap is basically empty.  That's OK, I suspect I'll be spending the next couple of weeks fixing all sorts of surprises.

But anyway, it's pretty cool to see that our GC increments are less than 1ms in most cases.

[pizlo@murderface OpenSource] DYLD_FRAMEWORK_PATH=WebKitBuild/Release/ WebKitBuild/Release/jsc splay.js --logGC=true --useConcurrentGC=true
[GC: 33504 kb => EdenCollection, 0.279337 ms...]
[Increment: 0.103959 ms...]
[Increment: 0.479143 ms...]
[Increment: 0.226833 ms...]
[Increment: 0.257257 ms...]
[Increment: 0.372514 ms...]
[Increment: 0.311635 ms...]
[Increment: 37545 kb, 0.248094 ms, cycle 11.331259 ms]
0.8380413055419922 ms.
0.6349086761474609 ms.
0.5240440368652344 ms.
0.47898292541503906 ms.
0.5850791931152344 ms.
0.6089210510253906 ms.
0.49495697021484375 ms.
0.5421638488769531 ms.
0.4799365997314453 ms.
0.5300045013427734 ms.
0.6458759307861328 ms.
0.5328655242919922 ms.
0.5369186401367188 ms.
0.6768703460693359 ms.
[GC: 71418 kb => FullCollection, 0.037991 ms...]
0.7328987121582031 ms.
0.6759166717529297 ms.
0.6589889526367188 ms.
0.7581710815429688 ms.
0.7989406585693359 ms.
[Increment: 0.091861 ms...]
1.1920928955078125 ms.
1.2500286102294922 ms.
3.584146499633789 ms.
0.7319450378417969 ms.
0.8029937744140625 ms.
0.7231235504150391 ms.
0.7059574127197266 ms.
[Increment: 72558 kb, 0.888023 ms, cycle 15.558143 ms]
3.4210681915283203 ms.
0.35309791564941406 ms.
0.3120899200439453 ms.
0.3139972686767578 ms.
0.3190040588378906 ms.
0.30994415283203125 ms.
0.2989768981933594 ms.
0.3390312194824219 ms.
0.3509521484375 ms.
0.5199909210205078 ms.
0.5590915679931641 ms.
0.43702125549316406 ms.
0.4699230194091797 ms.
0.5080699920654297 ms.
0.4429817199707031 ms.
0.4639625549316406 ms.
0.4620552062988281 ms.
0.5729198455810547 ms.
0.4551410675048828 ms.
0.4451274871826172 ms.
0.5478858947753906 ms.
0.4329681396484375 ms.
0.47707557678222656 ms.
0.5609989166259766 ms.
0.5578994750976562 ms.
0.47898292541503906 ms.
0.4658699035644531 ms.
0.5559921264648438 ms.
0.5049705505371094 ms.
0.4620552062988281 ms.
0.45490264892578125 ms.
0.5509853363037109 ms.
0.4839897155761719 ms.
0.4699230194091797 ms.
0.6778240203857422 ms.
0.7231235504150391 ms.
0.9000301361083984 ms.
0.5950927734375 ms.
0.48995018005371094 ms.
0.4761219024658203 ms.
0.6010532379150391 ms.
0.5438327789306641 ms.
0.5009174346923828 ms.
0.4909038543701172 ms.
1.3740062713623047 ms.
0.7390975952148438 ms.
0.9779930114746094 ms.
0.7410049438476562 ms.
0.6549358367919922 ms.
0.49686431884765625 ms.
0.5080699920654297 ms.
0.5168914794921875 ms.
0.42891502380371094 ms.
0.4990100860595703 ms.
0.45800209045410156 ms.
0.41794776916503906 ms.
0.5109310150146484 ms.
0.9129047393798828 ms.
0.5178451538085938 ms.
0.6561279296875 ms.
0.5919933319091797 ms.
0.5278587341308594 ms.
0.6549358367919922 ms.
0.5059242248535156 ms.
0.5059242248535156 ms.
0.5609989166259766 ms.
0.6628036499023438 ms.
0.5340576171875 ms.
0.4200935363769531 ms.
0.48995018005371094 ms.
0.4909038543701172 ms.
0.7088184356689453 ms.
0.9820461273193359 ms.
0.6070137023925781 ms.
0.41103363037109375 ms.
0.43582916259765625 ms.
0.47206878662109375 ms.
0.3781318664550781 ms.
0.3800392150878906 ms.
0.47016143798828125 ms.
0.3838539123535156 ms.
0.35500526428222656 ms.
0.4627704620361328 ms.
0.370025634765625 ms.
0.3619194030761719 ms.
0.4661083221435547 ms.
0.34689903259277344 ms.
0.34999847412109375 ms.
0.3509521484375 ms.
0.4649162292480469 ms.
0.3681182861328125 ms.
0.37789344787597656 ms.
0.5178451538085938 ms.
0.3578662872314453 ms.
0.35500526428222656 ms.
0.43892860412597656 ms.
0.3769397735595703 ms.
0.38886070251464844 ms.
0.45990943908691406 ms.
0.37097930908203125 ms.
0.3669261932373047 ms.
0.4611015319824219 ms.
0.392913818359375 ms.
0.4119873046875 ms.
0.4611015319824219 ms.
0.39696693420410156 ms.
0.4131793975830078 ms.
0.4589557647705078 ms.
0.39386749267578125 ms.
0.392913818359375 ms.
0.4100799560546875 ms.
0.5180835723876953 ms.
0.8227825164794922 ms.
0.3941059112548828 ms.
0.4870891571044922 ms.
0.37288665771484375 ms.
0.39005279541015625 ms.
[GC: 147241 kb => EdenCollection, 0.042141 ms...]
[Increment: 0.060120 ms...]
0.7369518280029297 ms.
0.5819797515869141 ms.
0.5249977111816406 ms.
0.5450248718261719 ms.
0.6401538848876953 ms.
0.5300045013427734 ms.
0.5409717559814453 ms.
0.6530284881591797 ms.
0.5338191986083984 ms.
0.5030632019042969 ms.
0.7169246673583984 ms.
0.6461143493652344 ms.
[Increment: 114106 kb, 0.310899 ms, cycle 8.867381 ms]
2.2020339965820312 ms.
0.13184547424316406 ms.
0.1289844512939453 ms.
0.1239776611328125 ms.
0.12612342834472656 ms.
0.12993812561035156 ms.
0.1289844512939453 ms.
0.14209747314453125 ms.
0.1289844512939453 ms.
0.1399517059326172 ms.
0.11992454528808594 ms.
0.12493133544921875 ms.
0.13494491577148438 ms.
0.12612342834472656 ms.
0.12803077697753906 ms.
0.12302398681640625 ms.
0.13303756713867188 ms.
0.13113021850585938 ms.
0.14090538024902344 ms.
0.12278556823730469 ms.
0.1239776611328125 ms.
0.1380443572998047 ms.
0.12803077697753906 ms.
0.12612342834472656 ms.
0.1919269561767578 ms.
0.1418590545654297 ms.
0.39386749267578125 ms.
0.6051063537597656 ms.
0.3540515899658203 ms.
0.2639293670654297 ms.
0.1850128173828125 ms.
0.16498565673828125 ms.
0.1628398895263672 ms.
0.1690387725830078 ms.
0.18405914306640625 ms.
0.2529621124267578 ms.
0.2040863037109375 ms.
0.2498626708984375 ms.
0.28014183044433594 ms.
0.4220008850097656 ms.
0.20194053649902344 ms.
0.12302398681640625 ms.
0.1270771026611328 ms.
0.1289844512939453 ms.
0.1239776611328125 ms.
0.11301040649414062 ms.
0.1239776611328125 ms.
0.1289844512939453 ms.
0.13589859008789062 ms.
0.12183189392089844 ms.
0.11897087097167969 ms.
0.11801719665527344 ms.
0.12493133544921875 ms.
0.1239776611328125 ms.
0.13399124145507812 ms.
0.11777877807617188 ms.
0.11801719665527344 ms.
0.11897087097167969 ms.
0.12803077697753906 ms.
0.11420249938964844 ms.
0.12612342834472656 ms.
0.2620220184326172 ms.
0.35500526428222656 ms.
0.4241466522216797 ms.
0.3230571746826172 ms.
0.35691261291503906 ms.
0.42700767517089844 ms.
0.3600120544433594 ms.
0.3800392150878906 ms.
0.3612041473388672 ms.
0.4050731658935547 ms.
0.36787986755371094 ms.
0.3459453582763672 ms.
0.4119873046875 ms.
0.3371238708496094 ms.
0.37598609924316406 ms.
0.43702125549316406 ms.
0.34117698669433594 ms.
0.35309791564941406 ms.
0.4150867462158203 ms.
0.36406517028808594 ms.
0.36907196044921875 ms.
0.38313865661621094 ms.
0.4382133483886719 ms.
0.3800392150878906 ms.
0.3418922424316406 ms.
0.4100799560546875 ms.
0.35691261291503906 ms.
0.3440380096435547 ms.
0.40721893310546875 ms.
0.3509521484375 ms.
0.347137451171875 ms.
0.34308433532714844 ms.
0.3960132598876953 ms.
0.4239082336425781 ms.
0.4429817199707031 ms.
0.46896934509277344 ms.
0.38695335388183594 ms.
0.34117698669433594 ms.
0.4019737243652344 ms.
0.35190582275390625 ms.
0.37598609924316406 ms.
0.6649494171142578 ms.
0.5428791046142578 ms.
0.3790855407714844 ms.
0.3669261932373047 ms.
0.4100799560546875 ms.
0.8211135864257812 ms.
0.3960132598876953 ms.
0.370025634765625 ms.
0.4558563232421875 ms.
0.35309791564941406 ms.
0.3619194030761719 ms.
0.4601478576660156 ms.
0.3800392150878906 ms.
0.3960132598876953 ms.
0.39196014404296875 ms.
0.4520416259765625 ms.
[GC: 189634 kb => FullCollection, 0.042795 ms...]
0.6458759307861328 ms.
[Increment: 0.070214 ms...]
0.6091594696044922 ms.
[Increment: 4386 kb, 0.254815 ms, cycle 1.780371 ms]
0.8368492126464844 ms.
0.16689300537109375 ms.
0.1590251922607422 ms.
0.1780986785888672 ms.
0.13780593872070312 ms.
0.1628398895263672 ms.
0.14495849609375 ms.
0.1308917999267578 ms.
0.13899803161621094 ms.
0.141143798828125 ms.
0.12493133544921875 ms.
0.537872314453125 ms.
0.7410049438476562 ms.
0.3910064697265625 ms.
0.2460479736328125 ms.
0.2319812774658203 ms.
0.33593177795410156 ms.
0.1919269561767578 ms.
0.16021728515625 ms.
0.1690387725830078 ms.
0.19598007202148438 ms.
0.14400482177734375 ms.
0.16498565673828125 ms.
0.14209747314453125 ms.
0.164031982421875 ms.
0.164031982421875 ms.
0.3120899200439453 ms.
0.13113021850585938 ms.
0.1430511474609375 ms.
0.12087821960449219 ms.
0.1270771026611328 ms.
0.1251697540283203 ms.
0.12612342834472656 ms.
0.12302398681640625 ms.
0.1289844512939453 ms.
0.1220703125 ms.
0.13709068298339844 ms.
0.11897087097167969 ms.
0.12111663818359375 ms.
0.12183189392089844 ms.
0.13899803161621094 ms.
0.12993812561035156 ms.
0.11992454528808594 ms.
0.1239776611328125 ms.
0.13017654418945312 ms.
0.12302398681640625 ms.
[GC: 190858 kb => EdenCollection, 0.022680 ms...]
0.21910667419433594 ms.
[Increment: 0.065105 ms...]
[Increment: 0.046877 ms...]
[Increment: 0.041202 ms...]
0.55694580078125 ms.
[Increment: 0.042442 ms...]
[Increment: 0.035807 ms...]
[Increment: 0.043993 ms...]
[Increment: 0.035148 ms...]
[Increment: 5332 kb, 0.193381 ms, cycle 1.293687 ms]
0.7498264312744141 ms.
0.14090538024902344 ms.
0.13113021850585938 ms.
0.1270771026611328 ms.
0.13494491577148438 ms.
0.1239776611328125 ms.
0.12493133544921875 ms.
0.12993812561035156 ms.
0.1289844512939453 ms.
0.1308917999267578 ms.
0.11992454528808594 ms.
0.11587142944335938 ms.
0.12612342834472656 ms.
0.10800361633300781 ms.
0.11110305786132812 ms.
0.11491775512695312 ms.
0.11301040649414062 ms.
0.10609626770019531 ms.
0.11610984802246094 ms.
0.11706352233886719 ms.
0.10895729064941406 ms.
0.11706352233886719 ms.
0.10204315185546875 ms.
0.10704994201660156 ms.
0.11301040649414062 ms.
0.11205673217773438 ms.
0.11301040649414062 ms.
0.11897087097167969 ms.
0.11181831359863281 ms.
0.11110305786132812 ms.
0.10800361633300781 ms.
0.10704994201660156 ms.
0.11587142944335938 ms.
0.11706352233886719 ms.
0.11587142944335938 ms.
0.11610984802246094 ms.
0.10418891906738281 ms.
0.10704994201660156 ms.
0.10895729064941406 ms.
0.12993812561035156 ms.
0.10800361633300781 ms.
0.11420249938964844 ms.
0.11014938354492188 ms.
0.10895729064941406 ms.
0.12111663818359375 ms.
0.12087821960449219 ms.
[GC: 190860 kb => EdenCollection, 0.025968 ms...]
[Increment: 0.047501 ms...]
0.3509521484375 ms.
[Increment: 0.054287 ms...]
[Increment: 0.036070 ms...]
[Increment: 0.043876 ms...]
0.4990100860595703 ms.
[Increment: 0.038487 ms...]
[Increment: 0.051859 ms...]
[Increment: 0.039268 ms...]
[Increment: 6054 kb, 0.142653 ms, cycle 1.301613 ms]
0.6330013275146484 ms.
0.10991096496582031 ms.
0.12111663818359375 ms.
0.11205673217773438 ms.
0.12111663818359375 ms.
0.11110305786132812 ms.
0.10585784912109375 ms.
0.11396408081054688 ms.
0.1049041748046875 ms.
0.11491775512695312 ms.
0.11587142944335938 ms.
0.10895729064941406 ms.
0.11396408081054688 ms.
0.11205673217773438 ms.
0.12302398681640625 ms.
0.10991096496582031 ms.
0.10895729064941406 ms.
0.1068115234375 ms.
0.11491775512695312 ms.
0.11205673217773438 ms.
0.11491775512695312 ms.
0.11706352233886719 ms.
0.1049041748046875 ms.
0.11205673217773438 ms.
0.11301040649414062 ms.
0.11396408081054688 ms.
0.1251697540283203 ms.
0.11181831359863281 ms.
0.10800361633300781 ms.
0.10609626770019531 ms.
0.10991096496582031 ms.
0.11086463928222656 ms.
0.12183189392089844 ms.
0.11205673217773438 ms.
0.11086463928222656 ms.
0.11110305786132812 ms.
0.11491775512695312 ms.
0.11205673217773438 ms.
0.12302398681640625 ms.
0.10895729064941406 ms.
0.10895729064941406 ms.
0.11491775512695312 ms.
0.10800361633300781 ms.
0.14901161193847656 ms.
0.1201629638671875 ms.
0.11610984802246094 ms.
[GC: 190862 kb => EdenCollection, 0.027128 ms...]
[Increment: 0.056724 ms...]
0.827789306640625 ms.
[Increment: 0.052050 ms...]
[Increment: 0.048763 ms...]
[Increment: 0.044044 ms...]
[Increment: 0.052477 ms...]
[Increment: 0.050246 ms...]
[Increment: 6986 kb, 0.081516 ms, cycle 1.225617 ms]
0.8141994476318359 ms.
0.11992454528808594 ms.
0.11610984802246094 ms.
0.15401840209960938 ms.
0.12087821960449219 ms.
0.11491775512695312 ms.
0.11491775512695312 ms.
0.11301040649414062 ms.
0.12111663818359375 ms.
0.11396408081054688 ms.
0.11110305786132812 ms.
0.11301040649414062 ms.
0.11301040649414062 ms.
0.10895729064941406 ms.
0.11992454528808594 ms.
0.11301040649414062 ms.
0.10800361633300781 ms.
0.11491775512695312 ms.
0.11205673217773438 ms.
0.10895729064941406 ms.
0.11801719665527344 ms.
0.10704994201660156 ms.
0.11205673217773438 ms.
0.12302398681640625 ms.
0.11181831359863281 ms.
0.11801719665527344 ms.
0.11992454528808594 ms.
0.11301040649414062 ms.
0.10800361633300781 ms.
0.11515617370605469 ms.
0.10800361633300781 ms.
0.11897087097167969 ms.
0.11396408081054688 ms.
0.11086463928222656 ms.
0.11587142944335938 ms.
0.12183189392089844 ms.
0.13113021850585938 ms.
0.12087821960449219 ms.
0.125885009765625 ms.
0.11706352233886719 ms.
0.1239776611328125 ms.
0.1220703125 ms.
0.1201629638671875 ms.
0.1220703125 ms.
0.12183189392089844 ms.
0.12803077697753906 ms.
[GC: 190865 kb => EdenCollection, 0.028420 ms...]
[Increment: 0.055186 ms...]
0.3540515899658203 ms.
[Increment: 0.047389 ms...]
[Increment: 0.044414 ms...]
[Increment: 0.036723 ms...]
0.49304962158203125 ms.
[Increment: 0.044291 ms...]
[Increment: 0.060881 ms...]
[Increment: 0.052198 ms...]
[Increment: 0.064555 ms...]
[Increment: 7834 kb, 0.181012 ms, cycle 1.459888 ms]
0.8139610290527344 ms.
0.13113021850585938 ms.
0.13303756713867188 ms.
0.11801719665527344 ms.
0.1239776611328125 ms.
0.12183189392089844 ms.
0.11706352233886719 ms.
0.11992454528808594 ms.
0.1289844512939453 ms.
0.12183189392089844 ms.
0.12302398681640625 ms.
0.12612342834472656 ms.
0.15115737915039062 ms.
0.1308917999267578 ms.
0.125885009765625 ms.
0.11801719665527344 ms.
0.44083595275878906 ms.
0.11801719665527344 ms.
0.11682510375976562 ms.
0.1270771026611328 ms.
0.12183189392089844 ms.
0.12993812561035156 ms.
0.1289844512939453 ms.
0.1270771026611328 ms.
0.11420249938964844 ms.
0.11897087097167969 ms.
0.10991096496582031 ms.
0.10800361633300781 ms.
0.11491775512695312 ms.
0.11014938354492188 ms.
0.11491775512695312 ms.
0.10991096496582031 ms.
0.11086463928222656 ms.
0.11801719665527344 ms.
0.11205673217773438 ms.
0.10991096496582031 ms.
0.11706352233886719 ms.
0.11301040649414062 ms.
0.11014938354492188 ms.
0.11301040649414062 ms.
0.11301040649414062 ms.
0.11491775512695312 ms.
0.10919570922851562 ms.
0.11801719665527344 ms.
0.11205673217773438 ms.
0.10991096496582031 ms.
[GC: 190867 kb => EdenCollection, 0.025759 ms...]
[Increment: 0.049976 ms...]
0.4010200500488281 ms.
[Increment: 0.046127 ms...]
[Increment: 0.044754 ms...]
[Increment: 0.039632 ms...]
[Increment: 0.036596 ms...]
[Increment: 0.055430 ms...]
[Increment: 0.039270 ms...]
[Increment: 8458 kb, 0.187435 ms, cycle 1.270033 ms]
0.9908676147460938 ms.
0.11706352233886719 ms.
0.11301040649414062 ms.
0.11396408081054688 ms.
0.11491775512695312 ms.
0.11420249938964844 ms.
0.11301040649414062 ms.
0.11110305786132812 ms.
0.12087821960449219 ms.
0.11396408081054688 ms.
0.11706352233886719 ms.
0.11515617370605469 ms.
0.11420249938964844 ms.
0.11301040649414062 ms.
0.11992454528808594 ms.
0.10895729064941406 ms.
0.11491775512695312 ms.
0.11301040649414062 ms.
0.11396408081054688 ms.
0.11682510375976562 ms.
0.11014938354492188 ms.
0.10895729064941406 ms.
0.11587142944335938 ms.
0.11706352233886719 ms.
0.11205673217773438 ms.
0.11897087097167969 ms.
0.10800361633300781 ms.
0.10919570922851562 ms.
0.11086463928222656 ms.
0.11181831359863281 ms.
0.11897087097167969 ms.
0.10991096496582031 ms.
0.11706352233886719 ms.
0.10919570922851562 ms.
0.11181831359863281 ms.
0.11086463928222656 ms.
0.1270771026611328 ms.
0.11515617370605469 ms.
0.10800361633300781 ms.
0.11014938354492188 ms.
0.11110305786132812 ms.
0.11897087097167969 ms.
0.11491775512695312 ms.
0.11396408081054688 ms.
0.11491775512695312 ms.
0.11205673217773438 ms.
[GC: 190868 kb => EdenCollection, 0.045988 ms...]
[Increment: 0.047249 ms...]
0.3330707550048828 ms.
[Increment: 0.062196 ms...]
[Increment: 0.039545 ms...]
[Increment: 0.057831 ms...]
[Increment: 0.049442 ms...]
[Increment: 0.045299 ms...]
0.7500648498535156 ms.
[Increment: 0.072236 ms...]
[Increment: 8825 kb, 0.154043 ms, cycle 1.294582 ms]
0.492095947265625 ms.
0.1499652862548828 ms.
0.1308917999267578 ms.
0.11920928955078125 ms.
0.11515617370605469 ms.
0.11920928955078125 ms.
0.11920928955078125 ms.
0.12803077697753906 ms.
0.11682510375976562 ms.
0.13518333435058594 ms.
0.1361370086669922 ms.
0.1289844512939453 ms.
0.13399124145507812 ms.
0.14209747314453125 ms.
0.12111663818359375 ms.
0.11181831359863281 ms.
0.11205673217773438 ms.
0.11205673217773438 ms.
0.12493133544921875 ms.
0.11110305786132812 ms.
0.11301040649414062 ms.
0.11491775512695312 ms.
0.11086463928222656 ms.
0.11706352233886719 ms.
0.11205673217773438 ms.
0.11086463928222656 ms.
0.11205673217773438 ms.
0.11181831359863281 ms.
0.11301040649414062 ms.
0.11706352233886719 ms.
0.11396408081054688 ms.
0.11706352233886719 ms.
0.11086463928222656 ms.
^C
[pizlo@murderface OpenSource]

[Filip Pizlo]

I'm making some progress, but I just realized that the whole OldGrey/NewGrey state arrangement is busted.  We need some other way of knowing if we're scanning an object due to the barrier versus due to marking.  I think that the only way to do it is to have separate mark stacks for the two things.

[Filip Pizlo]

Created attachment 294042 [details]
fixed some glaring flaws

I fixed the CellState bug.  But I still have more crashes.  I'm looking into them.

[Filip Pizlo]

Created attachment 294043 [details]
fixed some more races

[Filip Pizlo]

The GC is seeing objects with totally corrupt structure IDs.

Before going into this further, I'm going to add a collectContinuously mode. In this mode the GC will just always be running. After finishing a cycle it will immediately start another one. This way, the GC will be able to more effectively tell me what is going wrong.

I'm debugging with generational GC turned off, for now.  I'm also running in baseline JIT only, just to keep my reasoning about barriers super simple.

[Filip Pizlo]

Oh yeah, collectContinuously causes insta-crashes. Yusss.

[Filip Pizlo]

This is starting to look like an allocator bug: during concurrent GC we're allocating over live objects.

[Filip Pizlo]

Oh wow, MarkedBlock::stopAllocating() is totally wrong: it blows away newlyAllocated!

[Filip Pizlo]

(In reply to comment #12)
> Oh wow, MarkedBlock::stopAllocating() is totally wrong: it blows away
> newlyAllocated!

Hmmm, actually, no.  It blows it away but then it makes it right.

For a minute I was thinking that this was something that could only be right if you ran it at the top of GC and now just after the other increments.  But now I'm thinking it should work no matter what.  I'll have to stare at it more.

[Filip Pizlo]

Created attachment 294073 [details]
it can collect like seven times before crashing

Progress!

[Filip Pizlo]

Created attachment 294074 [details]
starting to work with useConcurrentJIT=false

Since it can collect concurrently like seven times, I'm going to focus on getting it to work properly with concurrent JIT disabled. That's shaking out some great bugs.

[Filip Pizlo]

(In reply to comment #15)
> Created attachment 294074 [details]
> starting to work with useConcurrentJIT=false
> 
> Since it can collect concurrently like seven times, I'm going to focus on
> getting it to work properly with concurrent JIT disabled. That's shaking out
> some great bugs.

This patch has concurrent GC turned off by default.  But even with it turned off, the collector uses the concurrent GC algorithm - it just happens to not stop the world.  As, the resumeTheWorld/stopTheWorld steps that let the mutator "peek" into the collector become no-ops by default.

Running in the default mode, this patch passes release stress tests.  I think it would pass debug stress tests, but I didn't have time to run that yet.  Next I'm going to run perf tests.  I want to see if the algorithm changes have any downside.  I moved *everything* into the fixpoint, which sounds completely insane but will probably work.

[Filip Pizlo]

Perf looks pretty good.  Earley-boyer seems to suffer a tiny amount, but it's so small that everything else dominates.

Benchmark report for SunSpider, LongSpider, V8Spider, Octane, and Kraken on murderface (MacBookPro11,5).

VMs tested:
"TipOfTree" at /Volumes/Data/secondary/OpenSource/WebKitBuild/Release/jsc (r208415)
"Things" at /Volumes/Data/quartary/OpenSource/WebKitBuild/Release/jsc (r208415)

Collected 6 samples per benchmark/VM, with 6 VM invocations per benchmark. Emitted a call to gc() between sample
measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime() function to
get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in milliseconds.

                                                TipOfTree                   Things                                      
SunSpider:
   3d-cube                                    4.6543+-0.1985            4.5880+-0.1519          might be 1.0144x faster
   3d-morph                                   4.9733+-0.5236            4.6632+-0.0704          might be 1.0665x faster
   3d-raytrace                                4.8796+-0.1170            4.7426+-0.0911          might be 1.0289x faster
   access-binary-trees                        1.9868+-0.0456            1.9820+-0.0273        
   access-fannkuch                            4.6442+-0.0544            4.6326+-0.0208        
   access-nbody                               2.4148+-0.1143            2.3866+-0.0195          might be 1.0118x faster
   access-nsieve                              2.8643+-0.0539     ?      2.9159+-0.0734        ? might be 1.0180x slower
   bitops-3bit-bits-in-byte                   1.1027+-0.0325     ?      1.2118+-0.3253        ? might be 1.0990x slower
   bitops-bits-in-byte                        2.8341+-0.3422            2.8235+-0.1780        
   bitops-bitwise-and                         1.9563+-0.0462            1.9475+-0.0655        
   bitops-nsieve-bits                         3.0322+-0.0615     ?      3.0410+-0.0758        ?
   controlflow-recursive                      2.2526+-0.0470            2.2355+-0.0233        
   crypto-aes                                 4.4888+-0.4054            4.2827+-0.0895          might be 1.0481x faster
   crypto-md5                                 2.6647+-0.0324     ?      2.6871+-0.0474        ?
   crypto-sha1                                2.7382+-0.1244     ?      2.8190+-0.2968        ? might be 1.0295x slower
   date-format-tofte                         16.8900+-0.9105     ?     17.0853+-0.3842        ? might be 1.0116x slower
   date-format-xparb                          4.4812+-0.1455     ?      4.5485+-0.1469        ? might be 1.0150x slower
   math-cordic                                2.8697+-0.2316            2.6656+-0.0488          might be 1.0766x faster
   math-partial-sums                          3.8592+-0.0745     ?      4.0898+-0.4652        ? might be 1.0597x slower
   math-spectral-norm                         1.9767+-0.0319     ?      1.9777+-0.0539        ?
   regexp-dna                                 6.1549+-0.1894     ?      6.1847+-0.2166        ?
   string-base64                              4.6369+-0.3612            4.4716+-0.0142          might be 1.0370x faster
   string-fasta                               5.5486+-0.4466            5.5181+-0.4154        
   string-tagcloud                            8.2368+-0.1453     ?      8.4959+-0.8993        ? might be 1.0315x slower
   string-unpack-code                        18.4797+-1.4757     ?     18.5741+-1.0569        ?
   string-validate-input                      4.1176+-0.0767     ?      4.1991+-0.0953        ? might be 1.0198x slower

   <arithmetic>                               4.7976+-0.0605     ?      4.7988+-0.0630        ? might be 1.0003x slower

                                                TipOfTree                   Things                                      
LongSpider:
   3d-cube                                  796.6859+-3.4323     ?    802.4174+-8.6311        ?
   3d-morph                                 564.8069+-2.6500          563.4614+-5.6709        
   3d-raytrace                              450.1907+-5.5140          447.8473+-4.4544        
   access-binary-trees                      782.3699+-4.4056     !    803.0864+-6.6461        ! definitely 1.0265x slower
   access-fannkuch                          237.3627+-17.3768    ?    238.7651+-14.7861       ?
   access-nbody                             504.9757+-7.3845          501.2820+-3.8414        
   access-nsieve                            284.8110+-7.8961     ?    285.1713+-7.8544        ?
   bitops-3bit-bits-in-byte                  32.3470+-1.3215           31.6697+-0.8888          might be 1.0214x faster
   bitops-bits-in-byte                       80.9715+-4.3220           79.9835+-2.9511          might be 1.0124x faster
   bitops-nsieve-bits                       367.7198+-7.7535          366.4823+-2.4768        
   controlflow-recursive                    392.9243+-4.5229     !    403.9003+-4.1975        ! definitely 1.0279x slower
   crypto-aes                               548.5693+-9.9136     ?    554.0095+-5.9220        ?
   crypto-md5                               457.0292+-7.5387          447.3692+-4.6003          might be 1.0216x faster
   crypto-sha1                              589.6957+-7.9802     ?    594.2150+-7.6857        ?
   date-format-tofte                       1813.2402+-33.2766    ?   1891.7206+-49.8909       ? might be 1.0433x slower
   date-format-xparb                        608.4417+-7.1466     ?    609.6717+-4.3487        ?
   hash-map                                 144.2038+-5.2630          136.7168+-3.1750          might be 1.0548x faster
   math-cordic                              401.6302+-3.9656     ?    402.5130+-3.5004        ?
   math-partial-sums                        280.8901+-2.2271     ?    281.9106+-2.6997        ?
   math-spectral-norm                       515.9382+-2.1197     ?    516.2097+-1.8907        ?
   string-base64                            463.6923+-7.3667     ?    466.2891+-7.3822        ?
   string-fasta                             326.0897+-2.6372     ?    330.0834+-7.3534        ? might be 1.0122x slower
   string-tagcloud                          166.8835+-2.1662     ?    167.8648+-1.0380        ?

   <geometric>                              361.8928+-2.2011     ?    362.4446+-1.0470        ? might be 1.0015x slower

                                                TipOfTree                   Things                                      
V8Spider:
   crypto                                    34.0213+-0.3730     ?     34.3642+-0.3845        ? might be 1.0101x slower
   deltablue                                 48.3955+-1.3441           47.8869+-0.8933          might be 1.0106x faster
   earley-boyer                              34.0340+-0.2623     !     34.9547+-0.5792        ! definitely 1.0271x slower
   raytrace                                  19.0770+-0.4793           19.0127+-1.1457        
   regexp                                    50.1340+-0.4132     ?     50.5603+-0.5672        ?
   richards                                  38.6569+-1.1123     ?     38.7559+-1.5505        ?
   splay                                     29.3865+-1.9087           29.3505+-1.9975        

   <geometric>                               34.7139+-0.3425     ?     34.8708+-0.5579        ? might be 1.0045x slower

                                                TipOfTree                   Things                                      
Octane:
   encrypt                                   0.14854+-0.00068    ?     0.14884+-0.00067       ?
   decrypt                                   2.56205+-0.03023    ?     2.56335+-0.03696       ?
   deltablue                        x2       0.12147+-0.00249    ?     0.12154+-0.00170       ?
   earley                                    0.23961+-0.00311    !     0.24478+-0.00148       ! definitely 1.0216x slower
   boyer                                     4.16801+-0.14233    ?     4.27985+-0.10391       ? might be 1.0268x slower
   navier-stokes                    x2       4.59418+-0.01589          4.58541+-0.01552       
   raytrace                         x2       0.66039+-0.00236    ?     0.66632+-0.00751       ?
   richards                         x2       0.07899+-0.00172    ?     0.07903+-0.00146       ?
   splay                            x2       0.31385+-0.00404          0.31294+-0.00169       
   regexp                           x2      17.47013+-0.86970         16.53071+-0.86606         might be 1.0568x faster
   pdfjs                            x2      39.90159+-0.77920    ?    40.08696+-0.65414       ?
   mandreel                         x2      40.02323+-0.52727    ?    40.04263+-0.47942       ?
   gbemu                            x2      28.70460+-0.08240    ?    28.74844+-0.15101       ?
   closure                                   0.46705+-0.00338    ?     0.46912+-0.00273       ?
   jquery                                    6.36426+-0.06069          6.31704+-0.06484       
   box2d                            x2       8.67714+-0.08035    ?     8.73038+-0.07810       ?
   zlib                             x2     333.86896+-14.20706   ?   337.96054+-10.43803      ? might be 1.0123x slower
   typescript                       x2     610.23743+-10.09097       607.02995+-7.14881       

   <geometric>                               4.74041+-0.03229          4.73837+-0.01563         might be 1.0004x faster

                                                TipOfTree                   Things                                      
Kraken:
   ai-astar                                   91.343+-4.112             89.531+-1.629           might be 1.0202x faster
   audio-beat-detection                       35.676+-1.123             35.396+-0.223         
   audio-dft                                  94.508+-2.440      ?      95.222+-2.314         ?
   audio-fft                                  27.831+-1.151             27.355+-0.110           might be 1.0174x faster
   audio-oscillator                           42.682+-0.595      ?      42.765+-0.274         ?
   imaging-darkroom                           55.901+-0.566             55.734+-0.160         
   imaging-desaturate                         41.090+-0.255      ?      41.279+-0.809         ?
   imaging-gaussian-blur                      60.639+-2.839             56.744+-4.027           might be 1.0686x faster
   json-parse-financial                       32.320+-1.592      ?      33.612+-1.980         ? might be 1.0400x slower
   json-stringify-tinderbox                   21.055+-0.672      ?      21.161+-1.540         ?
   stanford-crypto-aes                        34.214+-0.300      ?      34.375+-0.309         ?
   stanford-crypto-ccm                        34.223+-2.449             31.231+-2.071           might be 1.0958x faster
   stanford-crypto-pbkdf2                     89.012+-1.871      ?      89.941+-3.485         ? might be 1.0104x slower
   stanford-crypto-sha256-iterative           29.116+-0.436      ?      29.578+-0.544         ? might be 1.0159x slower

   <arithmetic>                               49.258+-0.561             48.852+-0.339           might be 1.0083x faster

                                                TipOfTree                   Things                                      
Geomean of preferred means:
   <scaled-result>                           26.8946+-0.0535           26.8816+-0.0846          might be 1.0005x faster

[Filip Pizlo]

I need to make all of CodeBlock's visitChildren logic thread-safe.  It's not right now, but easily could be - there's already a lock for that.

[Filip Pizlo]

(In reply to comment #18)
> I need to make all of CodeBlock's visitChildren logic thread-safe.  It's not
> right now, but easily could be - there's already a lock for that.

Alternatively, I could have a revisitWithWorldStopped hook in SlotVisitor, and we could make the "bad" visitChidren methods use this.  You would use it like this:

void Blah::visitChildren(SlotVisitor& visitor)
{
    if (visitor.revisitWithWorldStopped())
        return;
    ... // some terrible race conditions
}

Where revisitWithWorldStopped() would initially check if the world is stopped already, and if it is, it would schedule the object to be revisited on a separate visit-while-world-is-stopped list.  When visited from that worklist, it would return false.

I'm not sure yet if I will need this.

[Filip Pizlo]

For objects that change structure every time a new property is added, the current regime of loading the structure and butterfly in the right order in the collector, and storing them in the right order in the mutator, totally works.

But this breaks as soon as we add properties without transition.  This happens for dictionaries and as an optimization.

It seems that the Structure is already grabbing locks in this case.  Maybe the right thing to do is to do the entire store and butterfly switcheroo while that lock is held. Then have the GC scan hold the Structure's lock if it's a dictionary or something.

[Filip Pizlo]

Created attachment 294098 [details]
fixing races in JSObject::visitChildren

If the main thread is allocating a butterfly while the GC is scanning the object then we have a funny concurrent copying-like case.  Fortunately, it's easy to fix.

If we're not in dictionary mode, then we just want the GC to see the old structure until the end of the transition. That's easy.

If we're in dictionary mode, then any dangerous mutator activity will already grab the Structure's lock. So, we just need to slave the other stuff inside the lock. So the lock will protect the object.

[Filip Pizlo]

(In reply to comment #21)
> Created attachment 294098 [details]
> fixing races in JSObject::visitChildren
> 
> If the main thread is allocating a butterfly while the GC is scanning the
> object then we have a funny concurrent copying-like case.  Fortunately, it's
> easy to fix.
> 
> If we're not in dictionary mode, then we just want the GC to see the old
> structure until the end of the transition. That's easy.
> 
> If we're in dictionary mode, then any dangerous mutator activity will
> already grab the Structure's lock. So, we just need to slave the other stuff
> inside the lock. So the lock will protect the object.

Aw snap, but what about arrays?

If we have indexed storage then we need to have some way of scanning the right subset of it.

One option is to resize arrays under a lock.  Maybe that would work.

Another option is to institute proper discipline with respect to the lengths: don't increase length until we've sanitized that space.

[Filip Pizlo]

(In reply to comment #22)
> (In reply to comment #21)
> > Created attachment 294098 [details]
> > fixing races in JSObject::visitChildren
> > 
> > If the main thread is allocating a butterfly while the GC is scanning the
> > object then we have a funny concurrent copying-like case.  Fortunately, it's
> > easy to fix.
> > 
> > If we're not in dictionary mode, then we just want the GC to see the old
> > structure until the end of the transition. That's easy.
> > 
> > If we're in dictionary mode, then any dangerous mutator activity will
> > already grab the Structure's lock. So, we just need to slave the other stuff
> > inside the lock. So the lock will protect the object.
> 
> Aw snap, but what about arrays?
> 
> If we have indexed storage then we need to have some way of scanning the
> right subset of it.
> 
> One option is to resize arrays under a lock.  Maybe that would work.
> 
> Another option is to institute proper discipline with respect to the
> lengths: don't increase length until we've sanitized that space.

Let me just elaborate.  With indexing storage, two kinds of things can happen that would make us nervous:

1) The butterfly is reallocated.  But this isn't actually scary because the array butterfly describes its own indexing storage length.

2) The lengths change.  Here we just need to ensure that when increasing the length, we clear the wilderness before actually changing the length.  It may be that we do this already, I will audit.

[Filip Pizlo]

(In reply to comment #23)
> (In reply to comment #22)
> > (In reply to comment #21)
> > > Created attachment 294098 [details]
> > > fixing races in JSObject::visitChildren
> > > 
> > > If the main thread is allocating a butterfly while the GC is scanning the
> > > object then we have a funny concurrent copying-like case.  Fortunately, it's
> > > easy to fix.
> > > 
> > > If we're not in dictionary mode, then we just want the GC to see the old
> > > structure until the end of the transition. That's easy.
> > > 
> > > If we're in dictionary mode, then any dangerous mutator activity will
> > > already grab the Structure's lock. So, we just need to slave the other stuff
> > > inside the lock. So the lock will protect the object.
> > 
> > Aw snap, but what about arrays?
> > 
> > If we have indexed storage then we need to have some way of scanning the
> > right subset of it.
> > 
> > One option is to resize arrays under a lock.  Maybe that would work.
> > 
> > Another option is to institute proper discipline with respect to the
> > lengths: don't increase length until we've sanitized that space.
> 
> Let me just elaborate.  With indexing storage, two kinds of things can
> happen that would make us nervous:
> 
> 1) The butterfly is reallocated.  But this isn't actually scary because the
> array butterfly describes its own indexing storage length.
> 
> 2) The lengths change.  Here we just need to ensure that when increasing the
> length, we clear the wilderness before actually changing the length.  It may
> be that we do this already, I will audit.

Yeah, this turned out to be easy, I think.

[Filip Pizlo]

I bet that SparseArrayValueMap will just have to be given a lock.  Yuck but who cares.

[Filip Pizlo]

It seems that we'll need a lock for ArrayStorage unshifting.  This lock can't go into the ArrayStorage itself since that's what's being shifted, so we need to put the lock into the JSCell header.  We've seen this coming, so this shouldn't be too bad.

Then there are these two transitions, that seem like they need to happen under a lock:

Contiguous -> ArrayStorage
Contiguous -> SlowPutArrayStorage

But maybe not?  What if the mutator protocol here was:

1) Build the ArrayStorage butterfly but artificially set the lengths to zero.
2) Install the ArrayStorage butterfly.
3) Change the structure.
4) Set the lengths to something real.

If the GC interleaves between (2) and (3), it will think that it has Contiguous with zero length.

If the GC interleaves between (3) and (4), it will think that it has ArrayStorage with zero length.

These are all fine outcomes because the act of changing the structure will trigger a barrier that causes this object to be rescanned.

[Filip Pizlo]

Created attachment 294110 [details]
making the array object model thread-safe

Who said making VMs concurrent was hard?

[Filip Pizlo]

Created attachment 294172 [details]
implementing more of JSObject thread safety

[Filip Pizlo]

Man, I had to change the visitChildren algo again.

[Filip Pizlo]

Created attachment 294191 [details]
more

Making the JSObject::visitChildren story more rugged.

[Filip Pizlo]

Created attachment 294193 [details]
fixed LockAlgorithm

[Filip Pizlo]

Created attachment 294205 [details]
more fixes

There was a race in the allocator.

[Filip Pizlo]

I'm now to the point where I can run ~20 GCs in debug mode with collectContinuously=true.

The next problem is that Structure property tables are getting cleared by GC!  This turns out to be easier to fix than it seems.

[Filip Pizlo]

(In reply to comment #33)
> I'm now to the point where I can run ~20 GCs in debug mode with
> collectContinuously=true.
> 
> The next problem is that Structure property tables are getting cleared by
> GC!  This turns out to be easier to fix than it seems.

I started working on a fix that involved more locking, but I think that literally all we want to do is this:

- materializePropertyMap returns the map it created.
- Nobody accesses propertyTable() directly.  We might as well kill the method.

[Filip Pizlo]

Created attachment 294324 [details]
more

Hopefully fixes races in Structure.  I haven't tested it yet so it's probably totally broken.

[Filip Pizlo]

(In reply to comment #35)
> Created attachment 294324 [details]
> more
> 
> Hopefully fixes races in Structure.  I haven't tested it yet so it's
> probably totally broken.

It now crashed after 40 GCs.  Progress!

[Filip Pizlo]

Created attachment 294327 [details]
rebased

I moved the type profiler stuff into the fixpoint.

[Filip Pizlo]

I think that now is the time to get this patch ready to land.

[Filip Pizlo]

*** Bug 163734 has been marked as a duplicate of this bug. ***

[Filip Pizlo]

*** Bug 164421 has been marked as a duplicate of this bug. ***

[Filip Pizlo]

*** Bug 164422 has been marked as a duplicate of this bug. ***

[Filip Pizlo]

Created attachment 294449 [details]
more

[Filip Pizlo]

(In reply to comment #42)
> Created attachment 294449 [details]
> more

This looks like it's passing all tests with concurrent GC disabled.

That's pretty impressive considering that I basically redid how butterfly resizing works, how structure transition work, and how property tables work.  And a bunch of other random stuff.

I'll need to perf test the heck out of it.

[Filip Pizlo]

This latest patch is a perf regression.  So far I've ruled out the JSCell lock and the CASing of indexingType.

[Filip Pizlo]

I fixed the perf regression - it was a goof-up in Structure::willStoreValueSlow.

[Filip Pizlo]

(In reply to comment #45)
> I fixed the perf regression - it was a goof-up in
> Structure::willStoreValueSlow.

Nope, there are still regressions in raytrace and earley-boyer.  Investigating...

[Filip Pizlo]

(In reply to comment #46)
> (In reply to comment #45)
> > I fixed the perf regression - it was a goof-up in
> > Structure::willStoreValueSlow.
> 
> Nope, there are still regressions in raytrace and earley-boyer. 
> Investigating...

Fixed raytrace.  I need PutStructure to have a store-store fence, which means "read world" in B3, so that's what I did in DFG.  But in DFG, reading "world" also means reading the Stack.  Saying read(Heap) fixes the regression by reenabling PutStack sinking.

In reality, we can do a lot better than read(Heap).  I think we just need read(JSCell_butterfly).  We're just trying to ensure that the collector sees the new butterfly before it sees the new structure.

[Filip Pizlo]

(In reply to comment #47)
> (In reply to comment #46)
> > (In reply to comment #45)
> > > I fixed the perf regression - it was a goof-up in
> > > Structure::willStoreValueSlow.
> > 
> > Nope, there are still regressions in raytrace and earley-boyer. 
> > Investigating...
> 
> Fixed raytrace.  I need PutStructure to have a store-store fence, which
> means "read world" in B3, so that's what I did in DFG.  But in DFG, reading
> "world" also means reading the Stack.  Saying read(Heap) fixes the
> regression by reenabling PutStack sinking.
> 
> In reality, we can do a lot better than read(Heap).  I think we just need
> read(JSCell_butterfly).  We're just trying to ensure that the collector sees
> the new butterfly before it sees the new structure.

And in B3, we want the fence to read both cell and butterfly, but if we do that, we might as well tell B3 that we read top.

[Filip Pizlo]

This looks solid.  The SunSpider speed-up is because I reenabled get_by_val optimizations in the interpreter, which had rotted.


Benchmark report for SunSpider, LongSpider, V8Spider, Octane, and Kraken on murderface (MacBookPro11,5).

VMs tested:
"TipOfTree" at /Volumes/Data/secondary/OpenSource/WebKitBuild/Release/jsc (r208572)
"Things" at /Volumes/Data/quartary/OpenSource/WebKitBuild/Release/jsc (r208572)

Collected 6 samples per benchmark/VM, with 6 VM invocations per benchmark. Emitted a call to gc() between sample
measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime() function to
get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in milliseconds.

                                                TipOfTree                   Things                                      
SunSpider:
   3d-cube                                    4.6329+-0.1621            4.3330+-0.2411          might be 1.0692x faster
   3d-morph                                   4.7904+-0.3229            4.7441+-0.2330        
   3d-raytrace                                5.0711+-0.4142            4.6228+-0.2068          might be 1.0970x faster
   access-binary-trees                        1.9572+-0.1032     ?      2.1412+-0.4795        ? might be 1.0940x slower
   access-fannkuch                            4.6572+-0.0538            4.6122+-0.0388        
   access-nbody                               2.5723+-0.3846     ?      2.5841+-0.4337        ?
   access-nsieve                              2.9089+-0.0261     ?      2.9672+-0.4163        ? might be 1.0200x slower
   bitops-3bit-bits-in-byte                   1.1012+-0.0183     ?      1.2120+-0.3071        ? might be 1.1006x slower
   bitops-bits-in-byte                        2.7601+-0.0443            2.7576+-0.2210        
   bitops-bitwise-and                         1.9536+-0.0742            1.9235+-0.0289          might be 1.0157x faster
   bitops-nsieve-bits                         3.0381+-0.0209            3.0249+-0.0513        
   controlflow-recursive                      2.2578+-0.0247            2.2548+-0.0347        
   crypto-aes                                 4.2294+-0.0320     ^      3.8822+-0.0977        ^ definitely 1.0894x faster
   crypto-md5                                 2.6547+-0.0775     ^      2.4228+-0.0412        ^ definitely 1.0957x faster
   crypto-sha1                                2.6625+-0.0274     ?      2.7296+-0.4098        ? might be 1.0252x slower
   date-format-tofte                          6.7254+-0.1062            6.5362+-0.2849          might be 1.0289x faster
   date-format-xparb                          4.5343+-0.1318            4.5013+-0.2120        
   math-cordic                                2.7191+-0.1365            2.6643+-0.0688          might be 1.0206x faster
   math-partial-sums                          3.9062+-0.0978            3.8658+-0.0421          might be 1.0105x faster
   math-spectral-norm                         2.1088+-0.2363            1.9728+-0.0660          might be 1.0689x faster
   regexp-dna                                 6.1361+-0.1787     ?      6.2869+-0.3348        ? might be 1.0246x slower
   string-base64                              4.5725+-0.1887            4.4631+-0.0791          might be 1.0245x faster
   string-fasta                               5.3210+-0.0605     ?      5.3825+-0.1343        ? might be 1.0116x slower
   string-tagcloud                            8.1855+-0.1022     ?      8.3127+-0.2926        ? might be 1.0155x slower
   string-unpack-code                        19.0597+-1.0585           17.6160+-0.5405          might be 1.0820x faster
   string-validate-input                      4.1834+-0.0922            4.1259+-0.0566          might be 1.0139x faster

   <arithmetic>                               4.4115+-0.0469     ^      4.3054+-0.0521        ^ definitely 1.0247x faster

                                                TipOfTree                   Things                                      
LongSpider:
   3d-cube                                  797.8894+-10.0972    ?    799.3683+-17.2176       ?
   3d-morph                                 565.6757+-5.0217     ?    570.4503+-12.9570       ?
   3d-raytrace                              447.0399+-4.5722     ?    448.5900+-4.1094        ?
   access-binary-trees                      778.7185+-7.5747     !    818.2294+-6.5151        ! definitely 1.0507x slower
   access-fannkuch                          239.1625+-19.4045         237.3517+-10.9464       
   access-nbody                             503.7745+-4.2968     ?    507.3957+-7.6848        ?
   access-nsieve                            286.6103+-9.2922     ?    302.9953+-8.6683        ? might be 1.0572x slower
   bitops-3bit-bits-in-byte                  31.9382+-1.6052     ?     32.0247+-1.0816        ?
   bitops-bits-in-byte                       81.9702+-4.4997     ?     82.9207+-2.6455        ? might be 1.0116x slower
   bitops-nsieve-bits                       368.0507+-6.1664     ?    368.4164+-3.7404        ?
   controlflow-recursive                    392.4366+-3.3617     !    404.2294+-3.3785        ! definitely 1.0301x slower
   crypto-aes                               547.0616+-11.2789    ?    550.5072+-13.2570       ?
   crypto-md5                               446.7395+-3.9661     !    504.3682+-6.7520        ! definitely 1.1290x slower
   crypto-sha1                              592.2593+-11.5608    ?    598.6479+-9.4860        ? might be 1.0108x slower
   date-format-tofte                        327.9814+-6.0840     ?    338.2374+-10.6704       ? might be 1.0313x slower
   date-format-xparb                        608.7153+-3.4242     ^    599.8995+-2.3673        ^ definitely 1.0147x faster
   hash-map                                 137.3495+-5.7198          136.5254+-9.0635        
   math-cordic                              404.6788+-9.4474          398.8477+-2.4893          might be 1.0146x faster
   math-partial-sums                        283.9420+-6.3617          281.4028+-2.2569        
   math-spectral-norm                       515.7662+-4.3622     ?    517.7189+-4.9770        ?
   string-base64                            456.5683+-3.2441     ?    463.5931+-4.5822        ? might be 1.0154x slower
   string-fasta                             328.8064+-8.9068          328.4449+-3.1305        
   string-tagcloud                          166.9695+-1.7845          166.3598+-1.5795        

   <geometric>                              335.1229+-1.7944     !    339.5881+-0.8884        ! definitely 1.0133x slower

                                                TipOfTree                   Things                                      
V8Spider:
   crypto                                    33.8047+-0.2610           33.6964+-0.4699        
   deltablue                                 48.9495+-1.4640           48.4109+-1.9418          might be 1.0111x faster
   earley-boyer                              34.4457+-0.5239           33.7392+-0.5664          might be 1.0209x faster
   raytrace                                  19.3892+-0.6341           18.9264+-0.4473          might be 1.0245x faster
   regexp                                    51.3517+-1.8721           50.3249+-0.8108          might be 1.0204x faster
   richards                                  38.0634+-0.6105     ?     38.3580+-1.0538        ?
   splay                                     28.8504+-0.6703           28.5265+-0.8188          might be 1.0114x faster

   <geometric>                               34.8344+-0.3749           34.4237+-0.3374          might be 1.0119x faster

                                                TipOfTree                   Things                                      
Octane:
   encrypt                                   0.14976+-0.00197          0.14876+-0.00057       
   decrypt                                   2.54977+-0.01721    ?     2.55940+-0.02334       ?
   deltablue                        x2       0.11906+-0.00251    ?     0.12512+-0.00772       ? might be 1.0509x slower
   earley                                    0.23876+-0.00222    !     0.24311+-0.00131       ! definitely 1.0182x slower
   boyer                                     4.08303+-0.06643    ?     4.16980+-0.11650       ? might be 1.0213x slower
   navier-stokes                    x2       4.60187+-0.03652          4.58881+-0.02319       
   raytrace                         x2       0.66302+-0.00587    ?     0.66801+-0.00296       ?
   richards                         x2       0.07876+-0.00123          0.07816+-0.00078       
   splay                            x2       0.31729+-0.00947          0.31489+-0.00642       
   regexp                           x2      16.14372+-1.02212         16.07079+-0.91220       
   pdfjs                            x2      40.55879+-1.48527    ?    40.70498+-0.81888       ?
   mandreel                         x2      39.67059+-0.44861    ?    39.96994+-0.36386       ?
   gbemu                            x2      28.73509+-0.19885    ^    28.32307+-0.18504       ^ definitely 1.0145x faster
   closure                                   0.46418+-0.00242    ?     0.46541+-0.00263       ?
   jquery                                    6.29335+-0.02710    ?     6.31295+-0.04351       ?
   box2d                            x2       8.72286+-0.04169          8.65844+-0.04663       
   zlib                             x2     338.36141+-1.15147        334.31428+-9.66438         might be 1.0121x faster
   typescript                       x2     609.74150+-9.39796        600.95837+-8.22919         might be 1.0146x faster

   <geometric>                               4.71572+-0.03024    ?     4.72121+-0.03330       ? might be 1.0012x slower

                                                TipOfTree                   Things                                      
Kraken:
   ai-astar                                   89.479+-1.529             88.281+-2.154           might be 1.0136x faster
   audio-beat-detection                       35.365+-0.158      ?      35.630+-0.708         ?
   audio-dft                                  93.753+-3.230      ?      95.301+-3.322         ? might be 1.0165x slower
   audio-fft                                  27.891+-1.381             27.597+-0.360           might be 1.0106x faster
   audio-oscillator                           43.963+-2.397             42.928+-1.083           might be 1.0241x faster
   imaging-darkroom                           55.661+-0.614      ?      57.176+-2.403         ? might be 1.0272x slower
   imaging-desaturate                         44.491+-4.332             41.529+-1.227           might be 1.0713x faster
   imaging-gaussian-blur                      58.366+-2.593      ?      58.746+-3.943         ?
   json-parse-financial                       32.096+-0.254      ?      33.708+-1.515         ? might be 1.0502x slower
   json-stringify-tinderbox                   22.377+-1.317             20.960+-1.285           might be 1.0676x faster
   stanford-crypto-aes                        34.369+-0.588      ?      34.711+-0.208         ?
   stanford-crypto-ccm                        32.435+-2.721      ?      35.215+-3.871         ? might be 1.0857x slower
   stanford-crypto-pbkdf2                     89.275+-1.657      ?      89.751+-1.122         ?
   stanford-crypto-sha256-iterative           29.507+-0.405      ?      29.514+-0.178         ?

   <arithmetic>                               49.216+-0.309      ?      49.361+-0.718         ? might be 1.0029x slower

                                                TipOfTree                   Things                                      
Geomean of preferred means:
   <scaled-result>                           26.0305+-0.0912           25.9320+-0.0906          might be 1.0038x faster

[Filip Pizlo]

Created attachment 294512 [details]
the patch

[WebKit Commit Bot]

Attachment 294512 [details] did not pass style-queue:


ERROR: Source/WTF/wtf/LockAlgorithm.h:26:  Use #pragma once instead of #ifndef for header guard.  [build/header_guard] [5]
ERROR: Source/JavaScriptCore/runtime/JSObject.cpp:178:  One line control clauses should not use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/dfg/DFGOperations.cpp:508:  An else if statement should be written as an if statement when the prior "if" concludes with a return, break, continue or goto statement.  [readability/control_flow] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:549:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:552:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:555:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:560:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:576:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:580:  When wrapping a line, only indent 4 spaces.  [whitespace/indent] [3]
ERROR: Source/JavaScriptCore/runtime/JSObject.h:761:  The parameter name "structure" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/runtime/Structure.h:676:  The parameter name "vm" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/runtime/Structure.h:676:  The parameter name "table" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 12 in 63 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Filip Pizlo]

Created attachment 294526 [details]
fix some build errors

[WebKit Commit Bot]

Attachment 294526 [details] did not pass style-queue:


ERROR: Source/WTF/wtf/LockAlgorithm.h:26:  Use #pragma once instead of #ifndef for header guard.  [build/header_guard] [5]
ERROR: Source/JavaScriptCore/runtime/JSObject.cpp:178:  One line control clauses should not use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/dfg/DFGOperations.cpp:508:  An else if statement should be written as an if statement when the prior "if" concludes with a return, break, continue or goto statement.  [readability/control_flow] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:549:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:552:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:555:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:560:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:576:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:580:  When wrapping a line, only indent 4 spaces.  [whitespace/indent] [3]
ERROR: Source/JavaScriptCore/runtime/JSObject.h:761:  The parameter name "structure" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/runtime/Structure.h:676:  The parameter name "vm" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/runtime/Structure.h:676:  The parameter name "table" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 12 in 64 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Geoffrey Garen]

r=me

> Source/JavaScriptCore/dfg/DFGTierUpCheckInjectionPhase.cpp:67
> +        

Revert.

> Source/JavaScriptCore/heap/CellState.h:40
> +    // The object is going to be is in eden. During GC, this means that the object has not been marked yet.

I think you meant "is going to be in eden".

I'm not sure what you mean by the future tense here. Where are you before you are in eden?

> Source/JavaScriptCore/heap/ResumeTheWorldScope.h:24
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> + * THE POSSIBILITY OF SUCH DAMAGE.
> + */

Where's the rest of this? :P

> Source/JavaScriptCore/jit/Repatch.cpp:221
> +            

Revert.

> Source/JavaScriptCore/runtime/JSCell.h:121
> +    void lockInternalLock();
> +    void unlockInternalLock();
> +    
> +    class InternalLocker {
> +    public:
> +        InternalLocker(JSCell* cell)
> +            : m_cell(cell)
> +        {
> +            m_cell->lockInternalLock();
> +        }
> +        
> +        ~InternalLocker()
> +        {
> +            m_cell->unlockInternalLock();
> +        }

Why the special naming instead of WTF::Locker and lock()/unlock()?

I'm not sure that it's meaningful to call out this lock as "internal". We're making it public and claiming that it's available if you need it.

> Source/JavaScriptCore/runtime/JSCell.h:220
> +    // DO NOT store to this field. Always use a CAS loop, since some bits are flipped using CAS

Why are you yelling at me?

> Source/JavaScriptCore/runtime/JSObject.cpp:782
> +    WTF::storeStoreFence();
> +    setButterfly(vm, newButterfly);
> +    setStructure(vm, newStructure);

A little bit surprising that setStructure builds in a fence at the top but setButterfly doesn't. Kind of feels like either both should or neither should.

When I first read this code, it looked like an obvious missing fence between setButterfly and setStructure.

> Source/JavaScriptCore/runtime/Structure.h:192
> +    // These should be used with caution. Versions that take a func will call it after making the

I would remove "These should be used with caution". Abstract anxiety is no way to program.

> Source/JavaScriptCore/runtime/Structure.h:673
> +    // This will grab the lock. DO NOT call when holding the Structure's lock.

Why yelling?

[Geoffrey Garen]

Comment on attachment 294526 [details]
fix some build errors

r=me

[Filip Pizlo]

(In reply to comment #54)
> r=me
> 
> > Source/JavaScriptCore/dfg/DFGTierUpCheckInjectionPhase.cpp:67
> > +        
> 
> Revert.
> 
> > Source/JavaScriptCore/heap/CellState.h:40
> > +    // The object is going to be is in eden. During GC, this means that the object has not been marked yet.
> 
> I think you meant "is going to be in eden".
> 
> I'm not sure what you mean by the future tense here. Where are you before
> you are in eden?

Fixed.

> 
> > Source/JavaScriptCore/heap/ResumeTheWorldScope.h:24
> > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> > + * THE POSSIBILITY OF SUCH DAMAGE.
> > + */
> 
> Where's the rest of this? :P

I moved it to Heap.h/cpp as a nested class of Heap.  I'll remove this file.

> 
> > Source/JavaScriptCore/jit/Repatch.cpp:221
> > +            
> 
> Revert.

Reverted.

> 
> > Source/JavaScriptCore/runtime/JSCell.h:121
> > +    void lockInternalLock();
> > +    void unlockInternalLock();
> > +    
> > +    class InternalLocker {
> > +    public:
> > +        InternalLocker(JSCell* cell)
> > +            : m_cell(cell)
> > +        {
> > +            m_cell->lockInternalLock();
> > +        }
> > +        
> > +        ~InternalLocker()
> > +        {
> > +            m_cell->unlockInternalLock();
> > +        }
> 
> Why the special naming instead of WTF::Locker and lock()/unlock()?

I had it this way at first and it was super annoying:

- It would mean also implementing isHeld() or isLocked() or any other extra methods that Locker wants.  This approach frees us up to add more crap to Locker/Lock without having to worry about this lock also implementing all of those things.

- Writing JSCell::Locker locker(*cell), or Locker<JSCell> locker(*cell), led to awkward looking code. The trouble is that many cells, like Structure, also have an explicit lock for their state.  I think that we want to encourage most locking scenarios in subclasses of JSCell to introduce their own lock unless saving that one byte is actually meaningful.  That's because the more people use this cell lock, the more of a chance we have of overlocking leading to deadlocks.

- Writing cell->lock()/cell->unlock() in algorithms that cannot do structured locking was too much for me.  Considering all of the powers that cells have, "locking" them could mean so many things here.  When I first read it back to myself it felt like the "locking" had some other meaning, like that it was another word for "pinning".  That's how it reads when you see it in visitChildren().

I wanted unstructured locking code to look like it's actually locking a lock.  Then the other benefits - not having to implement all of the things that Locker/Lock do for each other and a more explicit syntax for structured locking - were icing.

> 
> I'm not sure that it's meaningful to call out this lock as "internal". We're
> making it public and claiming that it's available if you need it.

Not quite.  A public lock would be like the Java object monitor, which is a user-visible (as in, Java has syntax for locking it) lock.  This lock is not visible in that way and never will be.  It's for locking internal stuff that the user does not see.

It's important to call out the fact that this lock is already used internally, so that other clients know that they have to consider if their use of it would cause overlocking.

> 
> > Source/JavaScriptCore/runtime/JSCell.h:220
> > +    // DO NOT store to this field. Always use a CAS loop, since some bits are flipped using CAS
> 
> Why are you yelling at me?

I'll downcase it.

> 
> > Source/JavaScriptCore/runtime/JSObject.cpp:782
> > +    WTF::storeStoreFence();
> > +    setButterfly(vm, newButterfly);
> > +    setStructure(vm, newStructure);
> 
> A little bit surprising that setStructure builds in a fence at the top but
> setButterfly doesn't. Kind of feels like either both should or neither
> should.

A fraction of setButterfly() clients either avoid the fence altogether or accomplish the same effect through other means.

> 
> When I first read this code, it looked like an obvious missing fence between
> setButterfly and setStructure.

Yeah, it's weird.  I want to get a bit more experience with this before I come up with some idiom.

> 
> > Source/JavaScriptCore/runtime/Structure.h:192
> > +    // These should be used with caution. Versions that take a func will call it after making the
> 
> I would remove "These should be used with caution". Abstract anxiety is no
> way to program.

Removed.

> 
> > Source/JavaScriptCore/runtime/Structure.h:673
> > +    // This will grab the lock. DO NOT call when holding the Structure's lock.
> 
> Why yelling?

Fixed.

[Filip Pizlo]

It just ran splay to completion.


[pizlo@murderface OpenSource] DYLD_FRAMEWORK_PATH=WebKitBuild/Release/ WebKitBuild/Release/jsc splay.js --logGC=true --useConcurrentGC=true
[GC: START 33552 kb => EdenCollection, i#1 345+0 0.493677 ms...]
[GC: i#2 8+184 0.658550 ms...]
[GC: i#3 9+959 i#4 36429 kb, 0.957367 ms, cycle 14.717856 ms END]
[GC: START 70425 kb => FullCollection, i#1 347+0 0.153287 ms...]
[GC: i#2 12+93 0.306163 ms...]
[GC: i#3 9+432 0.782913 ms...]
[GC: i#4 11+1046 2.710367 ms...]
[GC: i#5 9+798 i#6 62896 kb, 0.969871 ms, cycle 26.478055 ms END]
[GC: START 128337 kb => EdenCollection, i#1 9+7770 0.167695 ms...]
[GC: i#2 7+3895 i#3 135788 kb, 1.384540 ms, cycle 18.322498 ms END]
[GC: START 202184 kb => FullCollection, i#1 349+0 0.142073 ms...]
[GC: i#2 13+145 0.350907 ms...]
[GC: i#3 8+1108 1.233849 ms...]
[GC: i#4 8+872 0.622759 ms...]
[GC: i#5 8+539 0.153844 ms...]
[GC: i#6 7+144 0.081525 ms...]
[GC: i#7 5+112 0.086980 ms...]
[GC: i#8 8+156 0.141430 ms...]
[GC: i#9 5+45 0.078518 ms...]
[GC: i#10 8+96 0.091217 ms...]
[GC: i#11 62917 kb, 0.134931 ms, cycle 16.691951 ms END]
[GC: START 205968 kb => EdenCollection, i#1 9+7708 0.110673 ms...]
[GC: i#2 8+3430 i#3 135801 kb, 1.141117 ms, cycle 16.588162 ms END]
[GC: START 206139 kb => FullCollection, i#1 349+0 0.275543 ms...]
[GC: i#2 10+208 0.448791 ms...]
[GC: i#3 10+1172 0.964068 ms...]
[GC: i#4 8+758 i#5 62633 kb, 0.635055 ms, cycle 16.055565 ms END]
[GC: START 206607 kb => EdenCollection, i#1 8+7745 0.084319 ms...]
[GC: i#2 9+3043 1.743988 ms...]
[GC: i#3 9+288 0.255459 ms...]
[GC: i#4 9+175 0.080615 ms...]
[GC: i#5 9+170 0.086541 ms...]
[GC: i#6 8+226 0.130024 ms...]
[GC: i#7 8+283 0.117449 ms...]
[GC: i#8 5+164 0.077049 ms...]
[GC: i#9 8+247 0.132028 ms...]
[GC: i#10 9+83 0.113649 ms...]
[GC: i#11 7+83 i#12 128445 kb, 0.158100 ms, cycle 18.573709 ms END]
[GC: START 206777 kb => FullCollection, i#1 350+0 0.110767 ms...]
[GC: i#2 12+289 0.388857 ms...]
[GC: i#3 10+1992 2.134810 ms...]
[GC: i#4 11+1003 i#5 64323 kb, 0.902219 ms, cycle 18.473984 ms END]
[GC: START 206636 kb => EdenCollection, i#1 7+7750 0.103415 ms...]
[GC: i#2 9+4725 i#3 145356 kb, 2.461469 ms, cycle 20.416298 ms END]
[GC: START 213050 kb => FullCollection, i#1 349+0 0.115077 ms...]
[GC: i#2 9+101 1.644228 ms...]
[GC: i#3 9+760 0.817250 ms...]
[GC: i#4 11+1249 1.262071 ms...]
[GC: i#5 7+1016 0.941544 ms...]
[GC: i#6 8+702 0.349539 ms...]
[GC: i#7 10+616 0.514468 ms...]
[GC: i#8 3+834 i#9 65649 kb, 0.610961 ms, cycle 23.119675 ms END]
[GC: START 221742 kb => EdenCollection, i#1 9+7744 0.109100 ms...]
[GC: i#2 8+4519 2.154213 ms...]
[GC: i#3 8+76 0.156852 ms...]
[GC: i#4 140522 kb, 0.194921 ms, cycle 19.053011 ms END]
[GC: START 221917 kb => FullCollection, i#1 351+0 0.111211 ms...]
[GC: i#2 12+307 0.347665 ms...]
[GC: i#3 8+1586 1.158651 ms...]
[GC: i#4 7+1414 i#5 64305 kb, 1.441439 ms, cycle 18.203774 ms END]
[GC: START 221740 kb => EdenCollection, i#1 9+7759 0.297416 ms...]
[GC: i#2 9+3089 i#3 132632 kb, 1.145373 ms, cycle 16.192337 ms END]
[GC: START 221900 kb => FullCollection, i#1 351+0 0.139488 ms...]
[GC: i#2 7+141 0.305244 ms...]
[GC: i#3 12+668 0.953892 ms...]
[GC: i#4 9+1594 1.001086 ms...]
[GC: i#5 9+1980 0.809432 ms...]
[GC: i#6 9+726 0.761457 ms...]
[GC: i#7 67168 kb, 0.148359 ms, cycle 20.699763 ms END]
[GC: START 221746 kb => EdenCollection, i#1 11+7768 0.100670 ms...]
[GC: i#2 9+4479 i#3 143538 kb, 1.917751 ms, cycle 17.648050 ms END]
[GC: START 221966 kb => FullCollection, i#1 351+0 0.111489 ms...]
[GC: i#2 11+481 0.465944 ms...]
[GC: i#3 9+1696 2.086538 ms...]
[GC: i#4 9+1409 0.416029 ms...]
[GC: i#5 6+273 0.110681 ms...]
[GC: i#6 7+117 0.066533 ms...]
[GC: i#7 10+151 0.098774 ms...]
[GC: i#8 64739 kb, 0.156934 ms, cycle 19.486586 ms END]
[GC: START 222568 kb => EdenCollection, i#1 9+7741 0.107954 ms...]
[GC: i#2 8+2532 i#3 130598 kb, 1.330904 ms, cycle 16.178564 ms END]
[GC: START 222722 kb => FullCollection, i#1 348+0 0.124211 ms...]
[GC: i#2 7+180 0.383652 ms...]
[GC: i#3 9+814 0.828189 ms...]
[GC: i#4 9+1695 0.746712 ms...]
[GC: i#5 8+1096 i#6 64991 kb, 1.495309 ms, cycle 20.386965 ms END]
[GC: START 222570 kb => EdenCollection, i#1 8+7714 0.265154 ms...]
[GC: i#2 9+4620 i#3 142279 kb, 1.723424 ms, cycle 17.096983 ms END]
[GC: START 222751 kb => FullCollection, i#1 350+0 0.116664 ms...]
[GC: i#2 14+105 1.445953 ms...]
[GC: i#3 9+466 3.536442 ms...]
[GC: i#4 11+1354 1.086112 ms...]
[GC: i#5 6+2102 0.854720 ms...]
[GC: i#6 8+1422 0.493480 ms...]
[GC: i#7 7+383 0.148204 ms...]
[GC: i#8 10+290 0.126087 ms...]
[GC: i#9 9+207 0.145574 ms...]
[GC: i#10 9+52 0.083253 ms...]
[GC: i#11 9+125 i#12 67036 kb, 0.298968 ms, cycle 22.364535 ms END]
[GC: START 222574 kb => EdenCollection, i#1 8+7742 0.096524 ms...]
[GC: i#2 7+4178 i#3 141902 kb, 1.688369 ms, cycle 17.184940 ms END]
[GC: START 222749 kb => FullCollection, i#1 349+0 0.116925 ms...]
[GC: i#2 13+250 4.387247 ms...]
[GC: i#3 10+932 1.395902 ms...]
[GC: i#4 8+1517 0.717660 ms...]
[GC: i#5 5+1523 0.538628 ms...]
[GC: i#6 9+721 0.246575 ms...]
[GC: i#7 8+49 0.060293 ms...]
[GC: i#8 8+138 0.106571 ms...]
[GC: i#9 8+138 0.138051 ms...]
[GC: i#10 65603 kb, 0.161353 ms, cycle 20.440389 ms END]
[GC: START 222571 kb => EdenCollection, i#1 7+7782 0.130068 ms...]
[GC: i#2 9+2559 i#3 132213 kb, 0.982078 ms, cycle 14.110867 ms END]
[GC: START 222727 kb => FullCollection, i#1 351+0 0.141261 ms...]
[GC: i#2 9+81 1.401724 ms...]
[GC: i#3 8+723 0.636521 ms...]
[GC: i#4 8+1545 0.828285 ms...]
[GC: i#5 8+2477 1.106273 ms...]
[GC: i#6 8+1830 i#7 69647 kb, 1.537630 ms, cycle 20.733063 ms END]
[GC: START 222579 kb => EdenCollection, i#1 6+7759 0.128467 ms...]
[GC: i#2 9+4756 i#3 153394 kb, 1.918306 ms, cycle 17.054953 ms END]
[GC: START 226856 kb => FullCollection, i#1 350+0 0.148927 ms...]
[GC: i#2 11+185 0.415485 ms...]
[GC: i#3 8+1293 0.953984 ms...]
[GC: i#4 9+1915 1.929904 ms...]
[GC: i#5 5+704 0.554566 ms...]
[GC: i#6 65451 kb, 0.219520 ms, cycle 20.218291 ms END]
[GC: START 236282 kb => EdenCollection, i#1 7+7722 0.113512 ms...]
[GC: i#2 8+4688 i#3 144558 kb, 1.909833 ms, cycle 16.823561 ms END]
[GC: START 236467 kb => FullCollection, i#1 348+0 0.162479 ms...]
[GC: i#2 10+166 0.277648 ms...]
[GC: i#3 3+739 0.536537 ms...]
[GC: i#4 10+2139 1.116680 ms...]
[GC: i#5 5+2451 0.956691 ms...]
[GC: i#6 6+1453 0.583437 ms...]
[GC: i#7 9+395 i#8 70605 kb, 0.505515 ms, cycle 19.491891 ms END]
[GC: START 236294 kb => EdenCollection, i#1 9+7798 0.217509 ms...]
[GC: i#2 6+4673 i#3 153915 kb, 1.897575 ms, cycle 19.039989 ms END]
[GC: START 236488 kb => FullCollection, i#1 350+0 0.241788 ms...]
[GC: i#2 10+105 0.288954 ms...]
[GC: i#3 8+1137 1.028772 ms...]
[GC: i#4 7+1724 0.870082 ms...]
[GC: i#5 9+1241 0.344709 ms...]
[GC: i#6 9+710 0.231342 ms...]
[GC: i#7 3+554 0.240464 ms...]
[GC: i#8 9+37 0.075323 ms...]
[GC: i#9 8+85 0.102286 ms...]
[GC: i#10 7+80 0.156847 ms...]
[GC: i#11 8+101 i#12 65921 kb, 0.291412 ms, cycle 18.211521 ms END]
[GC: START 236650 kb => EdenCollection, i#1 8+7718 0.134933 ms...]
[GC: i#2 11+4969 2.192672 ms...]
[GC: i#3 9+418 0.070402 ms...]
[GC: i#4 5+283 0.148422 ms...]
[GC: i#5 9+279 0.101878 ms...]
[GC: i#6 8+307 0.160850 ms...]
[GC: i#7 5+171 0.146026 ms...]
[GC: i#8 8+60 0.106129 ms...]
[GC: i#9 7+84 i#10 146143 kb, 0.262091 ms, cycle 21.332575 ms END]
[GC: START 236900 kb => FullCollection, i#1 349+0 0.270664 ms...]
[GC: i#2 10+22 0.163579 ms...]
[GC: i#3 10+291 0.659343 ms...]
[GC: i#4 8+1863 1.338649 ms...]
[GC: i#5 9+1674 0.692794 ms...]
[GC: i#6 3+933 0.246438 ms...]
[GC: i#7 8+316 0.104300 ms...]
[GC: i#8 8+204 0.111138 ms...]
[GC: i#9 8+164 0.110242 ms...]
[GC: i#10 7+108 0.116370 ms...]
[GC: i#11 65809 kb, 0.135361 ms, cycle 18.300530 ms END]
[GC: START 236682 kb => EdenCollection, i#1 7+7763 0.100141 ms...]
[GC: i#2 8+4578 i#3 143648 kb, 1.885794 ms, cycle 18.765390 ms END]
[GC: START 236864 kb => FullCollection, i#1 352+0 0.138014 ms...]
[GC: i#2 13+119 0.279890 ms...]
[GC: i#3 9+585 0.842670 ms...]
[GC: i#4 8+1552 1.038273 ms...]
[GC: i#5 9+1721 0.717225 ms...]
[GC: i#6 9+1737 0.828479 ms...]
[GC: i#7 7+623 i#8 68478 kb, 0.434242 ms, cycle 21.511182 ms END]
[GC: START 236688 kb => EdenCollection, i#1 10+7758 0.111822 ms...]
[GC: i#2 8+4387 i#3 149760 kb, 1.616397 ms, cycle 19.885638 ms END]
[GC: START 236879 kb => FullCollection, i#1 349+0 0.139003 ms...]
[GC: i#2 7+250 0.370981 ms...]
[GC: i#3 9+498 1.011678 ms...]
[GC: i#4 6+1508 0.835044 ms...]
[GC: i#5 7+1951 0.743418 ms...]
[GC: i#6 9+1368 0.458694 ms...]
[GC: i#7 7+678 0.315960 ms...]
[GC: i#8 7+74 0.097509 ms...]
[GC: i#9 9+61 0.119802 ms...]
[GC: i#10 67195 kb, 0.148897 ms, cycle 20.963915 ms END]
[GC: START 236685 kb => EdenCollection, i#1 10+7751 0.128840 ms...]
[GC: i#2 9+3281 i#3 144633 kb, 0.997987 ms, cycle 18.146723 ms END]
[GC: START 236866 kb => FullCollection, i#1 350+0 0.143923 ms...]
[GC: i#2 10+114 0.232214 ms...]
[GC: i#3 9+687 0.536601 ms...]
[GC: i#4 10+1400 1.003170 ms...]
[GC: i#5 10+2230 1.360193 ms...]
[GC: i#6 9+1681 0.587208 ms...]
[GC: i#7 10+644 0.208629 ms...]
[GC: i#8 10+223 0.114591 ms...]
[GC: i#9 10+287 0.178421 ms...]
[GC: i#10 4+11 i#11 69487 kb, 0.229193 ms, cycle 20.639782 ms END]
[GC: START 236690 kb => EdenCollection, i#1 7+7773 0.121401 ms...]
[GC: i#2 9+4564 i#3 153179 kb, 2.065649 ms, cycle 18.096229 ms END]
[GC: START 236886 kb => FullCollection, i#1 350+0 0.140237 ms...]
[GC: i#2 12+481 0.455854 ms...]
[GC: i#3 8+1608 0.751927 ms...]
[GC: i#4 8+1582 1.716295 ms...]
[GC: i#5 8+247 0.298860 ms...]
[GC: i#6 8+212 0.157799 ms...]
[GC: i#7 6+74 0.063702 ms...]
[GC: i#8 8+131 0.093912 ms...]
[GC: i#9 8+102 0.098492 ms...]
[GC: i#10 7+90 0.117927 ms...]
[GC: i#11 8+49 i#12 66085 kb, 0.267969 ms, cycle 20.602876 ms END]
[GC: START 239595 kb => EdenCollection, i#1 7+7742 0.120198 ms...]
[GC: i#2 6+5011 2.308638 ms...]
[GC: i#3 4+211 0.056816 ms...]
[GC: i#4 7+99 0.056386 ms...]
[GC: i#5 9+122 0.074453 ms...]
[GC: i#6 9+157 0.052663 ms...]
[GC: i#7 7+197 0.065547 ms...]
[GC: i#8 8+133 0.111621 ms...]
[GC: i#9 9+160 0.111678 ms...]
[GC: i#10 7+107 i#11 150077 kb, 0.178242 ms, cycle 21.706230 ms END]
[GC: START 239791 kb => FullCollection, i#1 349+0 0.122602 ms...]
[GC: i#2 11+34 0.154777 ms...]
[GC: i#3 8+2116 2.672754 ms...]
[GC: i#4 7+1793 0.713733 ms...]
[GC: i#5 9+367 0.075066 ms...]
[GC: i#6 7+272 0.084564 ms...]
[GC: i#7 8+294 0.100427 ms...]
[GC: i#8 5+275 0.129154 ms...]
[GC: i#9 5+9 0.084621 ms...]
[GC: i#10 5+101 i#11 66427 kb, 0.247166 ms, cycle 16.903431 ms END]
[GC: START 239595 kb => EdenCollection, i#1 9+7738 0.119798 ms...]
[GC: i#2 9+4209 i#3 146487 kb, 1.819645 ms, cycle 19.573858 ms END]
[GC: START 239783 kb => FullCollection, i#1 349+0 0.149297 ms...]
[GC: i#2 12+57 0.218939 ms...]
[GC: i#3 9+632 0.644771 ms...]
[GC: i#4 11+1057 1.625485 ms...]
[GC: i#5 8+1190 0.732295 ms...]
[GC: i#6 9+133 0.235577 ms...]
[GC: i#7 8+101 0.091153 ms...]
[GC: i#8 6+234 0.138114 ms...]
[GC: i#9 8+37 0.085238 ms...]
[GC: i#10 63555 kb, 0.145265 ms, cycle 19.143424 ms END]
[GC: START 239582 kb => EdenCollection, i#1 10+7742 0.139783 ms...]
[GC: i#2 9+5394 2.294339 ms...]
[GC: i#3 9+797 0.200683 ms...]
[GC: i#4 10+347 0.067734 ms...]
[GC: i#5 8+231 0.113077 ms...]
[GC: i#6 9+171 0.161923 ms...]
[GC: i#7 10+135 0.164770 ms...]
[GC: i#8 149005 kb, 0.151998 ms, cycle 22.839656 ms END]
[GC: START 239781 kb => FullCollection, i#1 345+0 0.154800 ms...]
[GC: i#2 9+50 0.771658 ms...]
[GC: i#3 8+925 0.948134 ms...]
[GC: i#4 9+1248 0.507021 ms...]
[GC: i#5 8+1369 0.463575 ms...]
[GC: i#6 10+1360 1.199352 ms...]
[GC: i#7 8+1828 1.203025 ms...]
[GC: i#8 8+729 0.335782 ms...]
[GC: i#9 9+205 0.154503 ms...]
[GC: i#10 8+52 0.073380 ms...]
[GC: i#11 9+170 0.179486 ms...]
[GC: i#12 68265 kb, 0.201204 ms, cycle 20.418650 ms END]
[GC: START 239593 kb => EdenCollection, i#1 8+7740 0.423915 ms...]
[GC: i#2 6+4220 i#3 150499 kb, 1.668941 ms, cycle 19.155693 ms END]
[GC: START 239785 kb => FullCollection, i#1 347+0 0.109034 ms...]
[GC: i#2 13+291 0.360502 ms...]
[GC: i#3 9+1193 0.689599 ms...]
[GC: i#4 9+1295 1.719639 ms...]
[GC: i#5 8+1256 0.558618 ms...]
[GC: i#6 9+589 0.177416 ms...]
[GC: i#7 11+310 0.122692 ms...]
[GC: i#8 9+170 0.096054 ms...]
[GC: i#9 8+91 0.110333 ms...]
[GC: i#10 65644 kb, 0.150167 ms, cycle 20.876351 ms END]
[GC: START 239587 kb => EdenCollection, i#1 9+7705 0.088938 ms...]
[GC: i#2 8+5039 2.357460 ms...]
[GC: i#3 8+63 0.060488 ms...]
[GC: i#4 9+107 0.055076 ms...]
[GC: i#5 9+185 0.062049 ms...]
[GC: i#6 7+202 0.066995 ms...]
[GC: i#7 8+114 0.100512 ms...]
[GC: i#8 9+94 0.072313 ms...]
[GC: i#9 10+113 0.086729 ms...]
[GC: i#10 5+111 i#11 148081 kb, 0.187620 ms, cycle 21.791070 ms END]
[GC: START 239780 kb => FullCollection, i#1 347+0 0.126674 ms...]
[GC: i#2 10+6 0.113702 ms...]
[GC: i#3 10+118 0.254016 ms...]
[GC: i#4 5+698 0.799605 ms...]
[GC: i#5 9+1774 1.117500 ms...]
[GC: i#6 9+1605 1.675619 ms...]
[GC: i#7 9+636 0.755726 ms...]
[GC: i#8 8+202 0.119626 ms...]
[GC: i#9 7+96 0.081232 ms...]
[GC: i#10 9+82 i#11 66517 kb, 0.229561 ms, cycle 21.122538 ms END]
[GC: START 239590 kb => EdenCollection, i#1 2+7765 0.112371 ms...]
[GC: i#2 10+4436 i#3 146380 kb, 1.828413 ms, cycle 16.068947 ms END]
[GC: START 239777 kb => FullCollection, i#1 350+0 0.116288 ms...]
[GC: i#2 9+162 0.297433 ms...]
[GC: i#3 5+1060 0.931635 ms...]
[GC: i#4 9+2126 0.933850 ms...]
[GC: i#5 9+1506 i#6 66649 kb, 1.019943 ms, cycle 18.154967 ms END]
[GC: START 239590 kb => EdenCollection, i#1 9+7695 0.272865 ms...]
[GC: i#2 9+5164 2.150236 ms...]
[GC: i#3 10+251 0.077299 ms...]
[GC: i#4 10+184 0.053418 ms...]
[GC: i#5 10+148 0.053592 ms...]
[GC: i#6 11+241 0.061538 ms...]
[GC: i#7 9+159 0.079254 ms...]
[GC: i#8 8+148 0.087755 ms...]
[GC: i#9 8+111 0.108831 ms...]
[GC: i#10 9+178 0.144233 ms...]
[GC: i#11 5+55 i#12 150619 kb, 0.140252 ms, cycle 20.551483 ms END]
[GC: START 239786 kb => FullCollection, i#1 348+0 0.129918 ms...]
[GC: i#2 10+71 0.219653 ms...]
[GC: i#3 9+853 0.971183 ms...]
[GC: i#4 8+1432 0.663677 ms...]
[GC: i#5 3+2030 0.693010 ms...]
[GC: i#6 9+1768 0.747446 ms...]
[GC: i#7 10+615 0.220639 ms...]
[GC: i#8 9+256 0.145777 ms...]
[GC: i#9 68227 kb, 0.136160 ms, cycle 19.080062 ms END]
[GC: START 239594 kb => EdenCollection, i#1 9+7728 0.090539 ms...]
[GC: i#2 6+3593 1.686293 ms...]
[GC: i#3 9+637 0.242231 ms...]
[GC: i#4 9+242 0.102872 ms...]
[GC: i#5 10+188 0.103467 ms...]
[GC: i#6 9+220 0.086800 ms...]
[GC: i#7 6+394 0.097491 ms...]
[GC: i#8 8+247 0.139882 ms...]
[GC: i#9 9+103 0.159150 ms...]
[GC: i#10 2+7 0.117144 ms...]
[GC: i#11 9+89 0.121952 ms...]
[GC: i#12 140794 kb, 0.156483 ms, cycle 18.471052 ms END]
[GC: START 239762 kb => FullCollection, i#1 344+0 0.110482 ms...]
[GC: i#2 13+176 0.551590 ms...]
[GC: i#3 9+1112 0.711363 ms...]
[GC: i#4 9+1469 1.134194 ms...]
[GC: i#5 9+1102 0.399878 ms...]
[GC: i#6 8+75 0.052591 ms...]
[GC: i#7 7+112 0.086660 ms...]
[GC: i#8 9+140 0.110441 ms...]
[GC: i#9 8+77 0.083647 ms...]
[GC: i#10 8+58 0.108189 ms...]
[GC: i#11 64879 kb, 0.174481 ms, cycle 18.594738 ms END]
[GC: START 239586 kb => EdenCollection, i#1 9+7748 0.093972 ms...]
[GC: i#2 9+3072 1.608519 ms...]
[GC: i#3 8+94 0.118842 ms...]
[GC: i#4 9+92 0.045508 ms...]
[GC: i#5 131853 kb, 0.165249 ms, cycle 14.332156 ms END]
[GC: START 239742 kb => FullCollection, i#1 347+0 0.161720 ms...]
[GC: i#2 11+16 0.115995 ms...]
[GC: i#3 8+151 0.578869 ms...]
[GC: i#4 9+916 0.667732 ms...]
[GC: i#5 7+1665 1.389671 ms...]
[GC: i#6 6+1346 i#7 64877 kb, 0.691510 ms, cycle 16.871345 ms END]
[GC: START 239586 kb => EdenCollection, i#1 9+7722 0.104756 ms...]
[GC: i#2 6+1124 i#3 128249 kb, 0.592552 ms, cycle 14.128793 ms END]
[GC: START 239734 kb => FullCollection, i#1 347+0 0.139099 ms...]
[GC: i#2 10+53 0.305237 ms...]
[GC: i#3 9+445 0.453785 ms...]
[GC: i#4 5+1356 0.987965 ms...]
[GC: i#5 6+1471 1.789807 ms...]
[GC: i#6 9+832 0.238185 ms...]
[GC: i#7 9+329 0.122481 ms...]
[GC: i#8 9+182 0.091711 ms...]
[GC: i#9 11+216 0.147305 ms...]
[GC: i#10 9+195 i#11 65760 kb, 0.283469 ms, cycle 21.137876 ms END]
[GC: START 239588 kb => EdenCollection, i#1 8+7763 0.114434 ms...]
[GC: i#2 9+4196 i#3 141149 kb, 1.675027 ms, cycle 16.996666 ms END]
[GC: START 239764 kb => FullCollection, i#1 350+0 0.153182 ms...]
[GC: i#2 11+155 0.293341 ms...]
[GC: i#3 9+589 0.475373 ms...]
[GC: i#4 11+1773 0.993984 ms...]
[GC: i#5 6+1046 1.318460 ms...]
[GC: i#6 9+1287 0.880922 ms...]
[GC: i#7 9+116 0.179351 ms...]
[GC: i#8 9+96 0.126604 ms...]
[GC: i#9 66647 kb, 0.262754 ms, cycle 20.165564 ms END]
[GC: START 239590 kb => EdenCollection, i#1 10+7754 0.182523 ms...]
[GC: i#2 9+4993 i#3 149483 kb, 1.980273 ms, cycle 18.194951 ms END]
[GC: START 239911 kb => FullCollection, i#1 348+0 0.144907 ms...]
[GC: i#2 13+31 0.142213 ms...]
[GC: i#3 8+157 0.262519 ms...]
[GC: i#4 8+917 0.812590 ms...]
[GC: i#5 9+2202 1.532259 ms...]
[GC: i#6 9+1621 i#7 67515 kb, 1.194115 ms, cycle 19.582476 ms END]
[GC: START 239656 kb => EdenCollection, i#1 9+7764 0.220074 ms...]
[GC: i#2 8+5179 i#3 151537 kb, 2.160553 ms, cycle 19.463687 ms END]
[GC: START 239852 kb => FullCollection, i#1 347+0 0.201199 ms...]
[GC: i#2 12+311 0.568948 ms...]
[GC: i#3 9+786 0.694300 ms...]
[GC: i#4 9+2402 1.045182 ms...]
[GC: i#5 8+1753 0.606924 ms...]
[GC: i#6 9+600 0.220772 ms...]
[GC: i#7 9+149 0.061052 ms...]
[GC: i#8 8+259 0.121420 ms...]
[GC: i#9 9+170 0.140996 ms...]
[GC: i#10 9+141 0.106559 ms...]
[GC: i#11 9+77 i#12 68110 kb, 0.270406 ms, cycle 19.978482 ms END]
[GC: START 239656 kb => EdenCollection, i#1 10+7779 0.159743 ms...]
[GC: i#2 6+3998 i#3 144462 kb, 1.338773 ms, cycle 16.424439 ms END]
[GC: START 239835 kb => FullCollection, i#1 345+0 0.153874 ms...]
[GC: i#2 11+30 0.204773 ms...]
[GC: i#3 9+290 0.347901 ms...]
[GC: i#4 9+873 0.733642 ms...]
[GC: i#5 9+1562 1.773751 ms...]
[GC: i#6 8+1748 1.670817 ms...]
[GC: i#7 9+76 0.077311 ms...]
[GC: i#8 65959 kb, 0.123447 ms, cycle 22.403982 ms END]
[GC: START 239652 kb => EdenCollection, i#1 8+7759 0.129737 ms...]
[GC: i#2 8+3557 i#3 144140 kb, 1.383083 ms, cycle 20.298647 ms END]
[GC: START 239835 kb => FullCollection, i#1 344+0 0.135026 ms...]
[GC: i#2 13+90 0.211175 ms...]
[GC: i#3 8+479 0.448289 ms...]
[GC: i#4 10+1600 1.137955 ms...]
[GC: i#5 9+1993 1.190663 ms...]
[GC: i#6 9+661 i#7 66702 kb, 0.502323 ms, cycle 17.886192 ms END]
[GC: START 239654 kb => EdenCollection, i#1 7+7749 0.089641 ms...]
[GC: i#2 10+4974 2.089595 ms...]
[GC: i#3 9+277 0.071982 ms...]
[GC: i#4 9+294 0.058991 ms...]
[GC: i#5 11+201 0.074735 ms...]
[GC: i#6 9+192 0.083142 ms...]
[GC: i#7 9+151 0.061745 ms...]
[GC: i#8 5+220 0.128029 ms...]
[GC: i#9 9+134 i#10 148324 kb, 0.317600 ms, cycle 19.965729 ms END]
[GC: START 239844 kb => FullCollection, i#1 348+0 0.285304 ms...]
[GC: i#2 10+155 0.355453 ms...]
[GC: i#3 7+607 0.536182 ms...]
[GC: i#4 7+1443 1.142294 ms...]
[GC: i#5 9+639 0.410027 ms...]
[GC: i#6 10+213 0.094293 ms...]
[GC: i#7 9+192 0.082433 ms...]
[GC: i#8 8+110 0.076096 ms...]
[GC: i#9 9+169 0.124560 ms...]
[GC: i#10 9+69 i#11 63724 kb, 0.231532 ms, cycle 15.913297 ms END]
[GC: START 239647 kb => EdenCollection, i#1 9+7711 0.087921 ms...]
[GC: i#2 9+4241 i#3 136673 kb, 1.497522 ms, cycle 17.307251 ms END]
[GC: START 239817 kb => FullCollection, i#1 346+0 0.102463 ms...]
[GC: i#2 11+255 0.341269 ms...]
[GC: i#3 10+1367 0.946089 ms...]
[GC: i#4 9+1547 1.058483 ms...]
[GC: i#5 9+1061 i#6 66163 kb, 1.000371 ms, cycle 18.734569 ms END]
[GC: START 239652 kb => EdenCollection, i#1 8+7750 0.642057 ms...]
[GC: i#2 8+5025 2.044720 ms...]
[GC: i#3 9+580 0.107944 ms...]
[GC: i#4 9+200 0.121026 ms...]
[GC: i#5 9+127 0.089354 ms...]
[GC: i#6 9+132 0.148741 ms...]
[GC: i#7 10+119 0.103803 ms...]
[GC: i#8 9+73 0.061778 ms...]
[GC: i#9 149291 kb, 0.114866 ms, cycle 19.924793 ms END]
[GC: START 239846 kb => FullCollection, i#1 347+0 0.152969 ms...]
[GC: i#2 11+8 0.121567 ms...]
[GC: i#3 7+379 0.858722 ms...]
[GC: i#4 9+689 0.581404 ms...]
[GC: i#5 9+920 0.418936 ms...]
[GC: i#6 9+1332 0.637736 ms...]
[GC: i#7 9+1189 0.746882 ms...]
[GC: i#8 9+1274 0.759600 ms...]
[GC: i#9 10+1213 i#10 67196 kb, 0.660051 ms, cycle 18.994065 ms END]
[GC: START 239654 kb => EdenCollection, i#1 9+7739 0.175211 ms...]
[GC: i#2 9+4508 i#3 146436 kb, 1.511181 ms, cycle 17.454435 ms END]
[GC: START 239839 kb => FullCollection, i#1 346+0 0.162369 ms...]
[GC: i#2 10+297 0.379543 ms...]
[GC: i#3 9+1027 0.906702 ms...]
[GC: i#4 10+1173 0.994984 ms...]
[GC: i#5 8+1469 0.510077 ms...]
[GC: i#6 9+916 0.292157 ms...]
[GC: i#7 6+206 0.142288 ms...]
[GC: i#8 7+178 0.111034 ms...]
[GC: i#9 8+49 0.098191 ms...]
[GC: i#10 65588 kb, 0.163039 ms, cycle 18.968021 ms END]
[GC: START 239650 kb => EdenCollection, i#1 9+7754 0.106749 ms...]
[GC: i#2 9+4867 i#3 146244 kb, 1.873473 ms, cycle 16.760680 ms END]
[GC: START 239839 kb => FullCollection, i#1 346+0 0.128724 ms...]
[GC: i#2 11+74 0.205345 ms...]
[GC: i#3 9+785 0.504610 ms...]
[GC: i#4 9+1967 0.989745 ms...]
[GC: i#5 9+1839 0.614617 ms...]
[GC: i#6 7+1461 0.495846 ms...]
[GC: i#7 8+473 i#8 68924 kb, 0.516365 ms, cycle 16.661626 ms END]
That took 3877.3388862609863 ms.
[pizlo@murderface OpenSource]

[Filip Pizlo]

Created attachment 294613 [details]
possible patch for landing

Still working on 32-bit.  Still testing ARM64.  Still doing browser benchmark testing.

[Filip Pizlo]

Created attachment 294616 [details]
more fixes

[WebKit Commit Bot]

Attachment 294616 [details] did not pass style-queue:


ERROR: Source/WTF/wtf/LockAlgorithm.h:26:  Use #pragma once instead of #ifndef for header guard.  [build/header_guard] [5]
ERROR: Source/JavaScriptCore/runtime/JSObject.cpp:178:  One line control clauses should not use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/dfg/DFGOperations.cpp:509:  An else if statement should be written as an if statement when the prior "if" concludes with a return, break, continue or goto statement.  [readability/control_flow] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:549:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:552:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:555:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:560:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:576:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:580:  When wrapping a line, only indent 4 spaces.  [whitespace/indent] [3]
ERROR: Source/JavaScriptCore/runtime/JSObject.h:761:  The parameter name "structure" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/runtime/Structure.h:675:  The parameter name "vm" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/runtime/Structure.h:675:  The parameter name "table" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 12 in 66 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Filip Pizlo]

Created attachment 294623 [details]
rebased and fixed

Rebasing uncovered new uses of API I removed.  This fixes those errors.

[WebKit Commit Bot]

Attachment 294623 [details] did not pass style-queue:


ERROR: Source/WTF/wtf/LockAlgorithm.h:26:  Use #pragma once instead of #ifndef for header guard.  [build/header_guard] [5]
ERROR: Source/JavaScriptCore/runtime/JSObject.cpp:178:  One line control clauses should not use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/dfg/DFGOperations.cpp:509:  An else if statement should be written as an if statement when the prior "if" concludes with a return, break, continue or goto statement.  [readability/control_flow] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:549:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:552:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:555:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:560:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:576:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:580:  When wrapping a line, only indent 4 spaces.  [whitespace/indent] [3]
ERROR: Source/JavaScriptCore/runtime/JSObject.h:761:  The parameter name "structure" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/runtime/Structure.h:675:  The parameter name "vm" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/runtime/Structure.h:675:  The parameter name "table" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 12 in 65 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Filip Pizlo]

The store barriers on PutStructure look like they're too much for ARM.  GC performance is also hurt but not nearly as much as construction time.

Something I can do is teach the DFG and B3 more about the fence in PutStructure.  For example, we don't need it at all if we hadn't messed with the butterfly before.  Also, currently the fence removes our ability to do store elimination on PutStructures, which means that we'll have a long chain of totally unnecessary fences in any object constructor.

[Filip Pizlo]

(In reply to comment #63)
> The store barriers on PutStructure look like they're too much for ARM.  GC
> performance is also hurt but not nearly as much as construction time.
> 
> Something I can do is teach the DFG and B3 more about the fence in
> PutStructure.  For example, we don't need it at all if we hadn't messed with
> the butterfly before.  Also, currently the fence removes our ability to do
> store elimination on PutStructures, which means that we'll have a long chain
> of totally unnecessary fences in any object constructor.

If we always initialize objects upon allocation so that the wilderness of not-yet-initialized properties is zero-filled then we don't need fences when setting the structure.  That's pretty sweet.

Last time I plated with this, adding code to initialize stuff upon allocation was not expensive.

I'm attempting this now.

[Filip Pizlo]

Created attachment 294688 [details]
with the object initialization and fewer fences

[Filip Pizlo]

VICTORY!  I'm testing the revised version of the patch that attempts to address ARM's woes.  For the first time, I worked up the courage to test the concurrent GC in anger.

This is the performance of splay normally (tip of tree or with my patch and --useConcurrentGC=false [i.e. the default]):

[pizlo@murderface OpenSource] DYLD_FRAMEWORK_PATH=WebKitBuild/Release/ WebKitBuild/Release/jsc splay.js
That took 3298.9039421081543 ms.
Above 99.9%: 11.776494979858398 ms.
Above 99%: 10.036780834197998 ms.
Above 97.5%: 4.4260969161987305 ms.
Above 95%: 2.412609100341797 ms.
Above 90%: 1.3552560806274414 ms.
Above 75%: 0.688254451751709 ms.
Above 50%: 0.4552687644958496 ms.
Above 0%: 0.3296610832214355 ms.

"Above 0%" is a funny way of saying "average".  Notice that normally, there is a 1% chance that one tick of splay will take about 10ms, while usually a tick of splay will take 0.33ms.  That's a ~30x slow-down that you might randomly experience while doing something in JavaScript, all because the garbage collector interrupted you.

This is the performance of splay with concurrent GC:

[pizlo@murderface OpenSource] DYLD_FRAMEWORK_PATH=WebKitBuild/Release/ WebKitBuild/Release/jsc splay.js --useConcurrentGC=true
That took 3011.0859870910645 ms.
Above 99.9%: 5.75716495513916 ms.
Above 99%: 2.2775816917419434 ms.
Above 97.5%: 1.5731096267700195 ms.
Above 95%: 1.1017203330993652 ms.
Above 90%: 0.7723274230957031 ms.
Above 75%: 0.5373270988464356 ms.
Above 50%: 0.39242477416992183 ms.
Above 0%: 0.3008724212646484 ms.

First of all, notice the "That took" number and ponder its wonderful significance.  This is incredible: splay with concurrent GC runs to completion faster than splay without concurrent GC.  I did not know that this was possible.  All of my previous investigations into concurrent GC showed that having concurrent collector activity slows you down, but about 5%, due to the combination of increased barrier costs, increased allocation costs, memory thrashing (the GC touches all of the heap at least once and this creates tons of contention with the mutator), and extra interruptions (the concurrent GC will tell the mutator to do things more times total than a non-concurrent one).  This GC was indeed engineered to minimize all of those things, except for barrier costs, which are much higher when the collector is running (2x worse if you isolate the cost of a heap cell store), and interruptions (it's just as bad as grey-stack CMR [my last concurrent GC] - they both interrupt the mutator about 5-10 times per cycle).  It turns out that choosing the crazy Steele-barrier GC strategy worked decisively: splay seems to run between 5-10% *faster* with concurrent GC enabled!  I think this is mostly because I avoided imposing any allocation tax, because the GC is parallel and is engineered to reduce the number of times it touches memory, and because the Steele barrier obliterates the floating garbage problem.

It's clear that the concurrency is doing its job.  It's also clear that there is room for improvement.  In the 1% case, your time to completion drops from 10ms to 2.28ms.  That's a pretty good improvement, but I was hoping for more.  Basically every probability bucket improves, all the way down to the average.

I think that the way to reduce worst-case times further is to reduce barrier costs and add a bit of time slicing to the collector's self-imposed pauses.

[Filip Pizlo]

I measured again, this time with the percentile that JetStream/splay-latency uses: 99.5%.

With concurrent GC:

[pizlo@murderface OpenSource] DYLD_FRAMEWORK_PATH=WebKitBuild/Release/ WebKitBuild/Release/jsc splay.js --useConcurrentGC=true
That took 3049.337148666382 ms.
Above 99.9%: 3.70328426361084 ms.
Above 99.5%: 2.3821544647216797 ms.
Above 99%: 1.983451843261719 ms.
Above 97.5%: 1.4173612594604492 ms.
Above 95%: 1.005887508392334 ms.
Above 90%: 0.7253777980804443 ms.
Above 75%: 0.5205585479736328 ms.
Above 50%: 0.3981184482574463 ms.
Above 0%: 0.30466816425323484 ms.

Without concurrent GC:

[pizlo@murderface OpenSource] DYLD_FRAMEWORK_PATH=WebKitBuild/Release/ WebKitBuild/Release/jsc splay.js
That took 3216.944932937622 ms.
Above 99.9%: 11.273026466369629 ms.
Above 99.5%: 10.571198463439941 ms.
Above 99%: 9.875433444976807 ms.
Above 97.5%: 4.339852333068848 ms.
Above 95%: 2.3518404960632324 ms.
Above 90%: 1.3059234619140625 ms.
Above 75%: 0.6617779731750488 ms.
Above 50%: 0.44040999412536624 ms.
Above 0%: 0.3214940786361694 ms.

So, the 99.5 percentile improves 4.4x.  That suggests that we will have a 4.4x JetStream/splay-latency progression.

[Filip Pizlo]

Created attachment 294724 [details]
it's a splay speed-up

I'm still debugging a bunch of issues.

[WebKit Commit Bot]

Attachment 294724 [details] did not pass style-queue:


ERROR: Source/WTF/wtf/LockAlgorithm.h:26:  Use #pragma once instead of #ifndef for header guard.  [build/header_guard] [5]
ERROR: Source/JavaScriptCore/runtime/JSObject.cpp:178:  One line control clauses should not use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/runtime/Structure.h:675:  The parameter name "vm" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/runtime/Structure.h:675:  The parameter name "table" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/dfg/DFGOperations.cpp:509:  An else if statement should be written as an if statement when the prior "if" concludes with a return, break, continue or goto statement.  [readability/control_flow] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:549:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:552:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:555:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:560:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:576:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:580:  When wrapping a line, only indent 4 spaces.  [whitespace/indent] [3]
ERROR: Source/JavaScriptCore/runtime/JSObject.h:761:  The parameter name "structure" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 12 in 71 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Build Bot]

Comment on attachment 294724 [details]
it's a splay speed-up

Attachment 294724 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/2515221

New failing tests:
imported/w3c/web-platform-tests/IndexedDB/key_invalid.htm

[Build Bot]

Created attachment 294733 [details]
Archive of layout-test-results from ews114 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews114  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Filip Pizlo]

(In reply to comment #71)
> Created attachment 294733 [details]
> Archive of layout-test-results from ews114 for mac-yosemite
> 
> The attached test failures were seen while running run-webkit-tests on the
> mac-debug-ews.
> Bot: ews114  Port: mac-yosemite  Platform: Mac OS X 10.10.5

I think I have a fix for this.

[Filip Pizlo]

Created attachment 294738 [details]
more fixes

Fixes ARM perf.

Fixes some builds.

Ought to fix a worker destruction crash.

[WebKit Commit Bot]

Attachment 294738 [details] did not pass style-queue:


ERROR: Source/WTF/wtf/LockAlgorithm.h:26:  Use #pragma once instead of #ifndef for header guard.  [build/header_guard] [5]
ERROR: Source/JavaScriptCore/runtime/JSObject.cpp:178:  One line control clauses should not use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/runtime/Structure.h:675:  The parameter name "vm" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/runtime/Structure.h:675:  The parameter name "table" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/dfg/DFGOperations.cpp:509:  An else if statement should be written as an if statement when the prior "if" concludes with a return, break, continue or goto statement.  [readability/control_flow] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:554:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:557:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:560:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:565:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:581:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:585:  When wrapping a line, only indent 4 spaces.  [whitespace/indent] [3]
ERROR: Source/JavaScriptCore/runtime/JSObject.h:761:  The parameter name "structure" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 12 in 71 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Filip Pizlo]

Created attachment 294739 [details]
more fixes

Removed the useless ResumeHeapAccessScope header.

[WebKit Commit Bot]

Attachment 294739 [details] did not pass style-queue:


ERROR: Source/WTF/wtf/LockAlgorithm.h:26:  Use #pragma once instead of #ifndef for header guard.  [build/header_guard] [5]
ERROR: Source/JavaScriptCore/runtime/JSObject.cpp:178:  One line control clauses should not use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/runtime/Structure.h:675:  The parameter name "vm" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/runtime/Structure.h:675:  The parameter name "table" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/dfg/DFGOperations.cpp:509:  An else if statement should be written as an if statement when the prior "if" concludes with a return, break, continue or goto statement.  [readability/control_flow] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:554:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:557:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:560:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:565:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:581:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:585:  When wrapping a line, only indent 4 spaces.  [whitespace/indent] [3]
ERROR: Source/JavaScriptCore/runtime/JSObject.h:761:  The parameter name "structure" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 12 in 69 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Filip Pizlo]

Created attachment 294740 [details]
more fixes

More ARM fixes.

[WebKit Commit Bot]

Attachment 294740 [details] did not pass style-queue:


ERROR: Source/WTF/wtf/LockAlgorithm.h:26:  Use #pragma once instead of #ifndef for header guard.  [build/header_guard] [5]
ERROR: Source/JavaScriptCore/runtime/JSObject.cpp:178:  One line control clauses should not use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/runtime/Structure.h:675:  The parameter name "vm" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/runtime/Structure.h:675:  The parameter name "table" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/dfg/DFGOperations.cpp:509:  An else if statement should be written as an if statement when the prior "if" concludes with a return, break, continue or goto statement.  [readability/control_flow] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:554:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:557:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:560:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:565:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:581:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/heap/Heap.cpp:585:  When wrapping a line, only indent 4 spaces.  [whitespace/indent] [3]
ERROR: Source/JavaScriptCore/runtime/JSObject.h:761:  The parameter name "structure" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 12 in 70 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Geoffrey Garen]

Comment on attachment 294740 [details]
more fixes

View in context: https://bugs.webkit.org/attachment.cgi?id=294740&action=review

r=me

I don't fully understand the fencing rules here. Let's discuss them in a group meeting. (We'll need everybody to understand these rules in the end.)

> PerformanceTests/ES6SampleBench/Air/benchmark.js:81
> +        print("iteration " + iteration);

Revert.

[Filip Pizlo]

Landed in https://trac.webkit.org/changeset/208720

[Filip Pizlo]

(In reply to comment #79)
> Comment on attachment 294740 [details]
> more fixes
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=294740&action=review
> 
> r=me
> 
> I don't fully understand the fencing rules here. Let's discuss them in a
> group meeting. (We'll need everybody to understand these rules in the end.)
> 
> > PerformanceTests/ES6SampleBench/Air/benchmark.js:81
> > +        print("iteration " + iteration);
> 
> Revert.

Reverted in https://trac.webkit.org/changeset/208721

[Filip Pizlo]

Fixed cloop in https://trac.webkit.org/changeset/208723

[Csaba Osztrogonác]

It broke the ARMv7 traditional build:
https://build.webkit.org/builders/JSCOnly%20Linux%20ARMv7%20Traditional%20Release/builds/2827

buildfix landed in https://trac.webkit.org/changeset/208728 
(same as you added to the ARMv7 Thumb2 assembler.)

[Chris Dumez]

There was a 1% Octane regression on Mac in the range where this landed. I have not identified which commit caused it but this patch seems the most suspicious in the range.

[Chris Dumez]

(In reply to comment #84)
> There was a 1% Octane regression on Mac in the range where this landed. I
> have not identified which commit caused it but this patch seems the most
> suspicious in the range.

EarleyBoyer: 5% worse
pdfJS: 6% worse
RayTrace: 6% worse

[Chris Dumez]

(In reply to comment #85)
> (In reply to comment #84)
> > There was a 1% Octane regression on Mac in the range where this landed. I
> > have not identified which commit caused it but this patch seems the most
> > suspicious in the range.
> 
> EarleyBoyer: 5% worse
> pdfJS: 6% worse
> RayTrace: 6% worse

Filed <rdar://problem/29281375>.

[Keith Miller]

I'm not sure but it looks like this patch breaks a jsc debug test: https://build.webkit.org/builders/Apple%20El%20Capitan%2032-bit%20JSC%20%28BuildAndTest%29/builds/4220