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