JDK-8275917 : Some locks shouldn't allow_vm_block
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 18
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-10-26
  • Updated: 2021-11-01
  • Resolved: 2021-10-28
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 18
18 masterFixed
Related Reports
Relates :  
Description
There are some safepoint checking locks that pass allow_vm_block as true that aren't actually taken out by the VM thread.  If allow_vm_block is true, that causes a NoSafepointVerifier after the lock is taken, which could unnecessarily delay safepoints.

We can't really change below to 'if !thread->is_Java_thread() && SafepointSynchronize::is_at_safepoint()' because G1 concurrent threads run through safepoints.  So it can be true that it's at a safepoint but trying to acquire a lock, such as the Heap_lock will not block the execution of the safepoint. So the check is somewhat narrow and special but it's still worth keeping.

     if (!_allow_vm_block && thread->is_VM_thread()) {
    // JavaThreads are checked to make sure that they do not hold _allow_vm_block locks during operations
    // that could safepoint.  Make sure the vm thread never uses locks with _allow_vm_block == false.
    fatal("VM thread could block on lock that may be held by a JavaThread during safepoint: %s", name());
     }
Comments
Changeset: bec977c7 Author: Coleen Phillimore <coleenp@openjdk.org> Date: 2021-10-28 11:57:21 +0000 URL: https://git.openjdk.java.net/jdk/commit/bec977c778a35ea48a45db662f1feaeab79308b2
28-10-2021