Integrated: 8307236: Rendezvous GC threads under STS for monitor deflation

[Roman Kennke]

On Wed, 3 May 2023 10:06:43 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. At least with the upcoming Compact Object Headers this is going to be a problem, because the compressed Klass* is then part of the mark-word.
> 
> 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 (most of them already are!). This will be implemented in later PR.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2

This pull request has now been integrated.

Changeset: 12d6ec66
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/12d6ec66a6cc668c929b3ebefd52a0dcac34771a
Stats:     26 lines in 4 files changed: 24 ins; 0 del; 2 mod

8307236: Rendezvous GC threads under STS for monitor deflation

Reviewed-by: eosterlund, shade

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

PR: https://git.openjdk.org/jdk/pull/13773