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

[Krystal Mok]

Hi Christine,

Thanks for your answers. The point on using more threads to slow down
mutators / speed up collectors is interesting.

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?

Thanks,
Kris

On Mon, Jan 20, 2014 at 12:13 PM, Christine Flood <chf at redhat.com> wrote:

> 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
> > > -----------
> > >
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140120/db61a277/attachment.htm>