JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector (original) (raw)

Krystal Mok rednaxelafx at gmail.com
Mon Jan 20 19:49:28 UTC 2014

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>

More information about the hotspot-gc-dev mailing list