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

    • Sub-task
    • Status: Resolved
    • P4
    • Resolution: Fixed
    • 18
    • 18
    • hotspot
    • 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

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

              Dates

                Created:
                Updated:
                Resolved: