Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8275917

Some locks shouldn't allow_vm_block

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 18
    • Fix Version/s: 18
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b22

      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());
           }

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              coleenp Coleen Phillimore
              Reporter:
              coleenp Coleen Phillimore
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: