Aleksey Shipilëv

Well, we can ask @robilad about this, but I think it would be easier to just hook your username: https://github.com/openjdk/jcstress/pull/118#issuecomment-1228288109

> Ok, this might sound silly - but how do I get an account there? I think I never had an account, and I can't register myself. Oh, I understand....

Yes, please! This is the only caveat I found about asciidoctor in weeks!

Performance: the worst case I can come up with is Serial Full GC that moves the entire heap full of smallest objects, like this: ``` public class Retain { static...

Could you also go to https://github.com/schrieveslaach/jmh/actions -- and enable testing workflows for your fork? This would test things. Thanks!

/contributor add @zhengyu123

Performance note: there is an intrinsic tradeoff here between the cost of acquiring the critical section vs the concurrency it unblocks for non-STW GCs and the cache improvements on non-GC...

> > This looks good but one question for ZGC, does ZGC need an OopMapCache::cleanup_old_entries() ? > > We still call `OopMapCache::cleanup_old_entries() ` after STW pause, but now concurrent phase...

> I would suggest to move `OopMapCache::trigger_cleanup();` from `VM_ShenandoahReferenceOperation::doit_epilogue()` to `VM_ShenandoahOperation::doit_prologue()` and add the call to ` VM_ZOperation` and ` VM_XOperation`'s `doit_epilogue()` Right. Surely, it would be better to move...

Thanks for reviews! @stefank, I assume you are fine with the way we (lightly) touched ZGC code?