JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector
Andrew Dinn
adinn at redhat.com
Mon Jan 20 14:32:51 UTC 2014
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