[master] RFR: Rendezvous GC threads under STS for monitor deflation

[Aleksey Shipilev]

On Tue, 26 Oct 2021 16:08:56 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Object monitors are deflated concurrently by the MonitorDeflationThread. It first unlinks monitors from objects (i.e. restore the original object header), then handshakes (with a no-op) all Java threads, and only then destroys the monitors. This way, Java threads can safely (and racily) access monitors before the handshake, because the monitors are guaranteed to still exist when a Java thread racily reads a mark-word that is being unlinked, and the monitor can safely be destroyed after the handshake, because all Java threads would then read the correct unlinked mark-word.
> 
> However, GC threads are not rendezvous'ed like that, and can read potentially dead monitors.
> 
> In order to safely access monitors via object headers concurrently from GC threads, we need to rendezvous them after unlinking and before destroying the monitors, just like Java threads do, via handshake. This is important so that concurrent GCs (ZGC, Shenandoah, G1) can safely access object's Klass* (and thus object size, layout, etc) during concurrent GC phases.
> 
> This only implements the parts that do the rendezvous, it still requires that affected concurrent GC threads are under SustainableThreadSet. This will be implemented in later PR.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [x] tier3
>  - [x] tier4

Marked as reviewed by shade (Committer).

-------------

PR: https://git.openjdk.java.net/lilliput/pull/27