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

[Roman Kennke]

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

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

Commit messages:
 - 8307236: Rendezvous GC threads under STS for monitor deflation

Changes: https://git.openjdk.org/jdk/pull/13773/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13773&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307236
  Stats: 18 lines in 2 files changed: 17 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13773.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13773/head:pull/13773

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