Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8176393 Fix Mutex ranking system
  3. JDK-8272797

Mutex with rank safepoint_check_never imply allow_vm_block

    XMLWordPrintable

    Details

    • Type: Sub-task
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 18
    • Fix Version/s: 18
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b13

      Description

      If a Mutex has safepoint_check_never, that should imply that the vm thread or gc threads can also block on it, ie. _allow_vm_block. This also makes these locks imply a NoSafepointVerifier once taken. Having locks that don't block for safepoint but can safepoint while holding the lock should be a configuration that we should disallow for simplicity.
      ie. if you can't safepoint while taking the lock, why allow safepoints while holding the lock?

      The allow_vm_block matrix looks like this:

       _allow_vm_block=true, _safepoint_check_always - after safepoint check and lock acquired NSV
       _allow_vm_block=true, _safepoint_check_never - after lock acquired NSV
       _allow_vm_block=false, _safepoint_check_always - after safepoint check and lock acquired, other safepoints ok
       _allow_vm_block=false, _safepoint_check_never - after lock acquired, safepoints are allowed (don't allow this!)

        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: