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

    • Icon: Sub-task Sub-task
    • Resolution: Fixed
    • Icon: P4 P4
    • 18
    • 18
    • hotspot
    • b13

      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!)

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

              Created:
              Updated:
              Resolved: