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

[Mikael Gerdin]

On Monday 20 January 2014 17.31.25 Kirk Pepperdine wrote:
> Hi Andrew,
> 
> I don’t have a complete list of activities that safe point but GC is only
> one of them. Code cache maintenance is another, biased locking also can
> cause safe pointing… and there are other activities when the JVM will
> decide to safe point.

I think deoptimization and biased lock revocation are the two main safepoint 
operations besides GC.

There's a bunch of other ones, such as PrintThreads and HeapWalk and whatnot, 
but I wouldn't do that against a latency-sensitive production environment :)

I agree that in many cases GC pauses dominate the safepoint times, but if you 
want to consistently meet a pause time goal you may need to avoid or optimize 
other kinds of safepoints as well.

/Mikael

> 
> Regards,
> Kirk
> 
> On Jan 20, 2014, at 3:32 PM, Andrew Dinn <adinn at redhat.com> wrote:
> > On 20/01/14 14:05, Florian Weimer wrote:
> >> Does your pause time goal only include strictly-GC related pause times,
> >> or other causes for stop-the-world pauses (not all of which are related
> >> to object reachability)?
> > 
> > What other causes for stop-the-world pauses are there that are not
> > strictly-GC related?
> > 
> > I don't really see that the question needs answering. Clearly, if any
> > such pauses exist in the execution of a given on the JVM independent of
> > the action of the GC and are not to do with the latter's operation then
> > Shenandoah is not going to remove them. The goal of Shenandoah can only
> > be to remove pause times caused by GC.
> > 
> > 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.
> > 
> > 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.
> > 
> > regards,
> > 
> > 
> > Andrew Dinn
> > -----------