-
Bug
-
Resolution: Fixed
-
P4
-
21, 22
-
b16
-
generic
-
generic
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8317509 | 21.0.2 | Aleksey Shipilev | P4 | Resolved | Fixed | b02 |
We currently handshake GC threads with monitor deflation by calling SuspendibleThreadSet::synchronize() and SuspendibleThreadSet::desynchronize(). This is somewhat problematic though, because GCs may use other mechanisms to sync their GC threads. In particular, ZGC uses ZRelocateQueue to do that.
Luckily, CollectedHeap comes with interfaces for exactly this purpose: CollectedHeap::safepoint_synchronize_begin() and CollectedHeap::safepoint_synchronize_end(). Those methods are implemented by ZGC to do the correct synchronization with ZRelocateQueue. All GCs which need that sort of synchronization are overriding these methods and delegate to STS methods, so we can replace the STS calls with the CollectedHeap calls.
Luckily, CollectedHeap comes with interfaces for exactly this purpose: CollectedHeap::safepoint_synchronize_begin() and CollectedHeap::safepoint_synchronize_end(). Those methods are implemented by ZGC to do the correct synchronization with ZRelocateQueue. All GCs which need that sort of synchronization are overriding these methods and delegate to STS methods, so we can replace the STS calls with the CollectedHeap calls.
- backported by
-
JDK-8317509 More generic way to handshake GC threads with monitor deflation
- Resolved
- relates to
-
JDK-8307236 Rendezvous GC threads under STS for monitor deflation
- Resolved
- links to
-
Commit openjdk/jdk21u/60001763
-
Commit openjdk/jdk/31c4e03d
-
Review openjdk/jdk21u/222
-
Review openjdk/jdk/15336
(1 links to)