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

[Kirk Pepperdine]

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.

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