JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector (original) (raw)

Mikael Gerdin mikael.gerdin at oracle.com
Mon Jan 20 16:41:23 UTC 2014

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 > -----------

More information about the hotspot-gc-dev mailing list