Stacks, safepoints, snapshotting and GC

[Ron Pressler]

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 applied-asynchrony.com(mailto:holger at applied-asynchrony.com)) 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