Stacks, safepoints, snapshotting and GC

Per Liden per.liden at
Tue Jan 7 12:58:48 UTC 2020

While we're on this topic I thought I could mention that part of the 
plans to make ZGC a true sub-millisecond max pause time GC includes 
removing thread stacks completely from the GC root set. I.e. in such a 
world ZGC will not scan any thread stacks (virtual or not) during STW, 
instead they will be scanned concurrently.

But we're not quite there yet...


On 12/19/19 1:52 PM, Ron Pressler wrote:
> This is a very good question. Virtual thread stacks (which are actually
> continuation stacks from the VM’s perspective) are not GC roots, and so are
> not scanned as part of the STW root-scanning. How and when they are scanned
> is one of the core differences between the default implementation and the
> new one, enabled with -XX:+UseContinuationChunks.
> Virtual threads shouldn’t make any impact on time-to-safepoint, and,
> depending on the implementation, they may or may not make an impact
> on STW young-generation collection. How the different implementations
> impact ZGC/Shenandoah, the non-generational low-pause collectors is yet
> to be explored and addressed. I would assume that their current impact
> is that they simply crash them :)
> - Ron
> On 19 December 2019 at 11:40:03, Holger Hoffstätte (holger at at wrote:
>> Hi,
>> Quick question - not sure if this is an actual issue or somethign that has
>> been addressed yet; pointers to docs welcome.
>> How does (or will) Loom impact stack snapshotting and TTSP latency?
>> There have been some amazing advances in GC with Shenandoah and ZGC recently,
>> but their low pause times directly depend on the ability to quickly reach
>> safepoints and take stack snapshots for liveliness analysis.
>> How will this work with potentially one or two orders of magnitude more
>> virtual thread stacks? If I understand correctly TTSP should only depend
>> on the number of carrier threads (which fortunately should be much lower
>> than in legacy designs), but somehow the virtual stacks stil need to be
>> scraped..right?
>> thanks,
>> Holger

More information about the loom-dev mailing list