<div dir="ltr">We're talking about compaction pause right.<div><br></div><div>Current full GC pause with Selective is Mark pause + scavenge pause + Sweep pause + compaction pause + shrink pause.</div><div><br></div><div>At 20Gb Moose workload, it's 17 sec + 25ms (avg, up to 68ms) + 1.5sec + ~20ms + 0 ms (up to 4ms)</div><div><br></div><div>The thing is that, research wise, Mark and sweep pauses can be incremental or concurrent. So only scavenge and compaction are problematic (hardly concurrent without redesigning the full memory manager in uncharted territories). That means that in theory with this design we can have max 20ms pause.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 9, 2018 at 6:26 PM Ben Coman <<a href="mailto:btc@openinworld.com">btc@openinworld.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, 9 Oct 2018 at 15:52, Clément Béra <<a href="mailto:bera.clement@gmail.com" target="_blank">bera.clement@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="ltr"><div>Solution:</div><div><br></div><div>As Ben suggested, one solution would be to organized the lilliputian single linked list as a per segment linked list. I did not do that because it would impact a lot free chunk organization, I changed it in the past and it takes 2 days to make sure I did not break anything in the production VM.</div><div dir="auto"><br></div><div dir="auto">So what I did instead first is to try to sort lilliputian while sweeping (which is almost free </div></div></div></blockquote><div><br></div><div>cool, thats good context. if fair to balance simplicity (i.e. reliability) versus optimization. </div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="ltr"><div dir="auto">I just need an extra variable and execution time is not really impacted), iterate over the lilliputian linked list while compacting segments, and since segments are in ascending addresses order, that meant I could iterate at most once over the lilliputian linked list while compacting (O(N^2) becomes O(N)). That reduced the stupid pathological cases from multiple seconds to multiple hundred ms. </div><div dir="auto"><br></div><div dir="auto">That was great, but still not enough (we target 16ms pause for 60fps apps). So in addition I annotated while sweeping each segment with their last lilliputian, which means that now I can iterate over the lilliputian linked list per segment and remove the remaining overhead, leading to compaction pauses of several ms. </div></div></div></blockquote><div><br></div><div>I missed that pauses were that small already.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="ltr"><div dir="auto">I still clear the lilliputians while iterating over the segment in compaction phase, clearing all the lilliputian of 1 segment at once is indeed now possible, but it has no real performance benefit IMO since it does not avoid any cache miss (prev lilliputian is in cache for the segment iteration and current one has just been read from memory). Current impl works so I've just kept it that way. <br></div><div dir="auto"><br></div><div dir="auto">Now what you suggest Ben is better, no sorting of lilliputian while sweeping, just keep a reference to the last lilliputian in the segment (first one found in the segment since they end up in reverse address order), and then clear all the segment lilliputians at once when compacting it. It was just easier to make it work the way I did from what was implemented when I did it.</div></div></div></blockquote><div><br></div><div>cool. nice to know my understanding was on the right track and how other practical matters affect it</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="ltr"><div dir="auto">I thought about doing something similar to what you described when I finished but I don't think it would impact that much performance (it does not remove read/writes with cache miss) so I was too lazy. <br></div><div dir="auto"><br></div><div dir="auto">Right now I have 2 development images, one matching the trunk and one with extra profiling changes for my paper, so it is difficult to change things. But I may do that later when I finish this paper or you can change it yourself.</div></div></div></blockquote><div><br></div><div>I'm sure I'd find it interesting to do so, but I'm already behind on some projects.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="ltr"><div dir="auto">Compiling with selective requires to change compactorClass and enable tempvectorreadbarrier in slang compilation setting. The only thing is that u cannot really snapshot right now with selective (the idea is to have both selective and planning so that snapshots use planning and the rest of the code use selective, see hybridcompactor, not sure that works so far though, because without full heap compaction snapshots are quite bigger).<br></div><div dir="auto"><br></div><div dir="auto">Damned that was a long mail. But you really nailed the problem. I've been dying to talk about that to someone I'm glad you asked :-)</div></div></div></blockquote><div><br></div><div>I'm glad I can prompt the creative process.</div><div><br></div><div>cheers -ben</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="ltr"><div>On Mon, Oct 8, 2018 at 3:17 PM Ben Coman <<a href="mailto:btc@openinworld.com" rel="noreferrer" target="_blank">btc@openinworld.com</a>> wrote:<br></div></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, 8 Oct 2018 at 02:08, <<a href="mailto:commits@source.squeak.org" rel="noreferrer" target="_blank">commits@source.squeak.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
ClementBera uploaded a new version of VMMaker to project VM Maker:<br><br>
SpurSelectiveCompactor compacts memory by selecting the memory segments with the most free space and compacting only those, to limit fragmentation while being really quick to perform. The algorithm is fast mostly because it does not update pointers: they are updated lazily during the next marking phase, so there is no need to read the fields of objects in other memory segments that the one compacted.<br>
<br>
The algorithm works as follow. First, a global sweep pass iterates over the memory linearly, changing unmarked objects to free chunks and concatenating free chunks. During the global sweep phase, the segments of the heap are analysed to determine the percentage of occupation. Second, the least occupied segments are compacted by copying the remaining live objects into an entirely free segment, called regionToFill (we detail later in the paragraph where regionToFill comes from), changing their values to forwarding objects and marking the free chunks as unavailable (removed from free list and marked as data objects). Third, the next marking phase removes all forwarders. Fourth, at the beginning of the next compaction phase the compacted segments from the previous GC can be entirely marked as free space (No need to check anything inside, there were only forwarders and trash data). One of the compacted segment is then selected as the segmentToFill, others are just marked as free chunks.<br>
<br>
<br>
The compaction is effectively partial, compacting only the most critical segments of the heap to limit fragmentation. Compaction time is crazy low, since a low number of objects are moved and pointer updated is lazily done during the next marking phase, while still preventing memory fragmentation.<br>
<br>
Now this works well when biasForGC is true, but when performing a snapshot, the compactor is just total crap (we need to figure out a solution).<br>
<br>
Performance trick for lilliputian chunks:<br>
+ Specific free chunks (called lilliputian, see isLilliputianSize:) are managed using a single linked list instead of a double linked list since there's not enough room in the free chunk for the back pointer. During the sweep phase this is not a problem since we're rebuilding the free chunk structure, but during selective compaction we're detaching free chunks from the free chunk structure and that can be horribly slow (10 seconds sometimes at 20Gb heap due to many iteration over the single linked list). To work around this problem, the sweep phase use lastLilliputianChunk variable to sort the lilliputian free chunk single linked list in ascending address order (See interceptAddFreeChunkWithBytes:at:). During the selective compation phase, the same variable is re-used to iterate at most once over the single linked list while detaching lilliputian chunks (See incrementalUnlinkSmallChunk:). In addition, each segment is annotated during the sweep phase with the last lilliputian chunk it<br>
holds. Hence, during the compaction phase, the linked list is iterated but the iteration can jump to the last chunk of the previous segment to compact.!<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Specific free chunks (called lilliputian, see isLilliputianSize:) are managed using a single linked list instead of a double linked list since there's not enough room in the free chunk for the back pointer. During the sweep phase this is not a problem since we're rebuilding the free chunk structure, but during selective compaction we're detaching free chunks from the free chunk structure and that can be horribly slow (10 seconds sometimes at 20Gb heap due to many iteration over the single linked list). To work around this problem, the sweep phase use lastLilliputianChunk variable to sort the lilliputian free chunk single linked list in ascending address order (See interceptAddFreeChunkWithBytes:at:). During the selective compation phase, the same variable is re-used to iterate at most once over the single linked list while detaching lilliputian chunks (See incrementalUnlinkSmallChunk:).<br></blockquote><div><br></div><div>Please excuse me that I only skimmed the implementation and so don't have a good grasp if what I'm saying is practical,</div><div>but anyway reading the above description a random idea floating along the wind found me... </div><div><br></div><div>Have you considered per-segment-Lilliputian-list?</div><div>Reserve the first word of each segment as the pointer to the segment's first free-Lilliputian-chunk. If it is null there are no free-Lilliputian-chunks in that segment. </div><div>The global sweep easily(?) knows which segment a Lilliputian-free-chunk belongs to and prepends to that per-segment list.</div><div><br></div><div>To combine all those separate per-segment lists into an overall-list...</div><div>split that reserved word into two parts... </div><div>* the LSB part provides an "offset" to the first element of the per-segment-list</div><div>* the MSB part provides a pointer to the next segment with a per-segment-list i.e. "next-per-segment-list". </div><div>Also btw, Lilliputian-free-chunks only require space to hold the "next-offset" within its segment</div><div><br></div><div>To allocate from the overall-list...</div><div> given a root pointer "X", follow to the first segment,</div><div> allocate chunk at "offset",<br> update "offset" with "next-offset",</div><div> if "offset" is zero, update "X" with "next-per-segment-list"</div><div><br></div><div>Reserve a second word at the start of each segment and you have a back pointer to the previous segment.</div><div>So when a segment is removed, its easy to remove all its Lilliputian-free-chunks out of the overall-list in one go.</div><div>The Lilliputian-free-chunk-overall-list would be like a double-linked-list with offshoots.</div><div><br></div><div>Maybe(?) then the Lilliputian never needs to be sorted, </div><div>and also doesn't need to be traversed when freeing a segment, just remove the segment from the overall-list.<br></div><div><br></div><div>cheers -ben</div><div><br></div><div><br></div><div>P.S. Please feel free to play "idea"-whac-a-mole. I've not put a lot of critical thinking into it. It was easier to share than stop it bubbling about.</div><div><a href="https://en.wikipedia.org/wiki/Whac-A-Mole" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Whac-A-Mole</a><br></div></div></div></div></div>
</blockquote></div><br clear="all"><div><br></div>
</blockquote></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><span style="font-size:12.8px">Clément Béra<br></span><span style="color:rgb(0,0,238)"><a href="https://clementbera.github.io/" target="_blank">https://clementbera.github.io/</a></span><div style="font-size:12.8px"><a href="https://clementbera.wordpress.com/" target="_blank">https://clementbera.wordpress.com/</a></div></div></div></div></div></div>