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

[Andrew Dinn]

On 20/01/14 17:04, Florian Weimer wrote:
> 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

No, indeed, Shenandoah is not going to remove those overheads from any
app which currently incurs them. It's not going to turn your sandwich
into a banquet either. But it should be of enormous benefit for most
programs which require large heaps yet still need to respond to events
in a timely fashion.

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

Ok, to any such lumpers: small print may apply.

regards,


Andrew Dinn
-----------
Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
(USA), Paul Hickey (Ireland)