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

[Krystal Mok]

Hi Andrew,

Comments inline below:

On Mon, Jan 20, 2014 at 6:32 AM, Andrew Dinn <adinn at redhat.com> wrote:
>
> 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.
>
> But Shenandoah will still have a fallback path when it finds out there
won't be enough room for concurrent evacuation, right? Will it stop
concurrent operations and fallback to a stop-the-world collection?
(Just FYI for others: for CMS users, a similar situation is called
"concurrent mode failure"; for G1 users, it'll be "evacuation failed", or
"(to-space exhausted)" in GC logs.)
And ditto for "allocation failure" case, where the allocation rate is just
too high for the concurrent collector to keep up with, will there be a
fallback path to stop-the-world collection?


> 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.
>
> That's nice to know. It answers my earlier question of scanning stacks.
Thanks!

Regards,
Kris


> regards,
>
>
> Andrew Dinn
> -----------
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140120/b0b3b606/attachment.htm>