JDK-8212107 : VMThread issues and cleanup
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 12
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-10-12
  • Updated: 2021-11-09
  • Resolved: 2020-09-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 16
16 b18Fixed
Related Reports
Relates :  
JDK-8253833 - mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread
Relates :  
JDK-8212108 - SafepointSynchronizer never ending counter (big enough)
Relates :  
JDK-8253794 - TestAbortVMOnSafepointTimeout never timeouts
Relates :  
JDK-8253778 - ShenandoahSafepoint::is_at_shenandoah_safepoint should not access VMThread state from other threads
Description
The VM thread code a few issue:
- It can create an extra safepoint directly after a safepoint.
- It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do.
- The exposure of the vm operation is dangerous if it's a handshake.
- The code is a hornets nest with the repetition of checks and branches
Comments
Changeset: 431338bc Author: Robbin Ehn <rehn@openjdk.org> Date: 2020-09-29 09:37:15 +0000 URL: https://git.openjdk.java.net/jdk/commit/431338bc
29-09-2020
When deopt (I'm looking at that now) and biased locking is using handshakes ([~pchilanomate]) and monitor deflation happens outside safepoint ([~dcubed]), and ICache removal ([~eosterlund]), because we almost only need GC safepoint. That makes the queue not needed. So this will be waiting for those 4 pieces, not for 13.
28-03-2019
Regarding vm_operation/calling_thread, I have not found a bug, but some-place are not trivial to verify that they are always correct. Just by not exposing those two directly we are much safer and you can embed proper assert inside the call instead of outside.
12-10-2018
I'm not expecting direct handshakes between JT's to involve VM-operations or the VM-operation queue. When between VMThread and JT then only vmThread is expected to touch current vm_operation(). Good point about coalescing and oops_do(). Though I'd have to see how the oops in the VM_operation get saved when the operation returns normally.
12-10-2018
If we use more handshakes more non-JavaThreads might touch the queue. In practice only coalesce RevokeBias, since the time you have to trigger a second safepoint is really short. I believe we don't need the queue if we do biased locking revocation with handshakes JT->JT (without VM thread involvement) as discussed. static VM_Operation* vm_operation() exposes the operation. If you do any concurrent operation (e.g. a handshake) it's not safe to touch that pointer is you are not the one executing the handshake, or in the ThreadClousure in the handshake. (this includes calling_thread() which exposes the VM Op creating/starting thread) Since we in practice never coalesce and with infinity number of combination, I'm not convinced that. E.g. is coalescing VM_HeapWalkOperation with GC pause really safe? Since the VM_HeapWalkOperation is remove from queue thus not visited in VMThread::oops_do ?
12-10-2018
There's a long-standing open issue about the VM_operation queue race. But it was recently claimed to not be a practical issue only theoretical. What do you mean by "exposure of the vm operation"? What safepoint operations can't be coalesced at a single safepoint? They are supposed to be "coalescable" - if not then what broke that?
12-10-2018