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

[Aleksey Shipilev]

On Thu, 4 May 2023 11:37:09 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
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Assert for safepoint instead of VMThread

src/hotspot/share/runtime/monitorDeflationThread.hpp line 45:

> 43:   bool is_hidden_from_external_view() const { return true; }
> 44: 
> 45:   bool is_monitor_deflation_thread() const override  { return true; }

Don't say "override" here, because clang would then trigger lots of warnings for methods that were not marked as such. See GHA failures :) Yes, it is unfortunate, but...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13773#discussion_r1185271224