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

Florian Weimer fweimer at redhat.com
Mon Jan 20 17:04:04 UTC 2014


On 01/20/2014 03:32 PM, Andrew Dinn 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?

Off the top of my head (mostly, admittedly):

GetPrimitiveArrayCritical/ReleasePrimitiveArrayCritical critical 
sections causing stalls (still somewhat GC-related)

finalizers and reference processing, in particular unmapping direct buffers

unbiasing biased locks

non-GC resource reclamation (e.g. object monitors)

java.lang.invoke.SwitchPoint invalidation

other deoptimizations and compilation-related activities

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

At least some of the above are often lumped together with GC pause 
times, so I think it's best to set appropriate expectations.

-- 
Florian Weimer / Red Hat Product Security Team



More information about the hotspot-gc-dev mailing list