JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector

[Christine Flood]

Concurrent Mark and Sweep falls back on full GC's because the old generation gets too fragmented.  
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.

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().

I reserve the right to reverse this position once we have more experience with Shenandoah.


Christine


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