<div dir="ltr">Hi Christine,<br><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks for your answers. The point on using more threads to slow down mutators / speed up collectors is interesting.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">What I was asking was mostly from a completeness perspective on the algorithm, not that the stop-the-world fallback will really happen in normal scenarios. It seems to me that, the way Shenandoah does concurrent evacuation through Brooks-style barrier will lead to it needing more headroom, and when there's not enough headroom it'll need to make sure it can handle all cases, right?</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,</div><div class="gmail_extra">Kris<br><br><div class="gmail_quote">On Mon, Jan 20, 2014 at 12:13 PM, Christine Flood <span dir="ltr"><<a href="mailto:chf@redhat.com" target="_blank">chf@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Concurrent Mark and Sweep falls back on full GC's because the old generation gets too fragmented.<br>
G1 falls back on full GC's because it is trying so hard to hit it's pause time goals that it can't keep up.<br>
<br>
We have a lot of work to do on heuristics for Shenandoah, but theoretically by allocating more threads to the garbage collector we can gently slow down the mutator enough for us to keep up.  The only reasons I see for a full GC fallback position are if we have a humongous object that we don't have enough contiguous space for or if the user explicity asks for a System.gc().<br>

<br>
I reserve the right to reverse this position once we have more experience with Shenandoah.<br>
<div class="im HOEnZb"><br>
<br>
Christine<br>
<br>
<br>
----- Original Message -----<br>
</div><div class="im HOEnZb">> From: "Krystal Mok" <<a href="mailto:rednaxelafx@gmail.com">rednaxelafx@gmail.com</a>><br>
> To: "Andrew Dinn" <<a href="mailto:adinn@redhat.com">adinn@redhat.com</a>><br>
> Cc: <a href="mailto:hotspot-gc-dev@openjdk.java.net">hotspot-gc-dev@openjdk.java.net</a><br>
> Sent: Monday, January 20, 2014 2:49:28 PM<br>
> Subject: Re: JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector<br>
><br>
</div><div class="HOEnZb"><div class="h5">> Hi Andrew,<br>
><br>
> Comments inline below:<br>
><br>
> On Mon, Jan 20, 2014 at 6:32 AM, Andrew Dinn <<a href="mailto:adinn@redhat.com">adinn@redhat.com</a>> wrote:<br>
> ><br>
> > n.b. the goal does not just apply to stop-the-world pauses. Shenandoah<br>
> > should not to stop any individual mutator from making significant<br>
> > progress for longer than 10 msecs. The present target is proposed in<br>
> > terms of 'stop-the-world pauses' because the GC algorithm includes a<br>
> > single stop-the-world pause to scan roots from all thread stacks. This<br>
> > is the expected to be by far the worst case pause for any individual<br>
> > thread. Other pauses imposed on individual threads because of memory<br>
> > management operations ought to be much smaller.<br>
> ><br>
> > But Shenandoah will still have a fallback path when it finds out there<br>
> won't be enough room for concurrent evacuation, right? Will it stop<br>
> concurrent operations and fallback to a stop-the-world collection?<br>
> (Just FYI for others: for CMS users, a similar situation is called<br>
> "concurrent mode failure"; for G1 users, it'll be "evacuation failed", or<br>
> "(to-space exhausted)" in GC logs.)<br>
> And ditto for "allocation failure" case, where the allocation rate is just<br>
> too high for the concurrent collector to keep up with, will there be a<br>
> fallback path to stop-the-world collection?<br>
><br>
><br>
> > A later version of Shenandoah is intended to optimize root scanning to<br>
> > process thread stacks round-robin, i.e. stopping only one thread at a<br>
> > time. This ought to give much smaller worst-case pause times for any<br>
> > given thread.<br>
> ><br>
> > That's nice to know. It answers my earlier question of scanning stacks.<br>
> Thanks!<br>
><br>
> Regards,<br>
> Kris<br>
><br>
><br>
> > regards,<br>
> ><br>
> ><br>
> > Andrew Dinn<br>
> > -----------<br>
> ><br>
> ><br>
><br>
</div></div></blockquote></div><br></div></div>