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

Check Mutex ranking during a safepoint

    XMLWordPrintable

    Details

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

      Description

      The Mutex rank checking is excluded during a safepoint likely for historical reasons when the Threads_lock or Safepoint_lock were held. It's better to not have this condition while rank checking, but removing it requires reassigning some Mutex ranks:

          owns -> takes (so reduce rank)

          SystemDictionary_lock(leaf) -> DumpTimeTable_lock(leaf-1) -> Zip_lock(leaf-2)
                                                                                                           -> Uncommit_lock(leaf-2)
                                                                                                           -> ConcurrentHashTableResize_lock(leaf-2)
                                                                                                           -> VtableStubs_lock(leaf-2)
                                                                                                           -> MetaspaceAllocation_lock(leaf -2)
                                                                                                                               ->Metaspace_lock(leaf-3)

          CGC_lock(leaf) -> RootRegionScan_lock(leaf-1)
                                   -> NonJavaThreadsListLock(leaf-1) -> G1DetachedRefinementStats_lock(leaf-2)

          FreeList_lock(leaf) -> Uncommit_lock(leaf-2) -> G1Mapper_lock(leaf-3)
                                             -> HeapRegionParAlloc_lock(leaf-1)


      If the Service_lock is only taken if not at_safepoint for oops_do/nmethods_do functions so we don't have to reduce the ranks of the G1 threads because of G1 locks taken at a safepoint. The code adding to the ServiceThread's jvmti deferred event queue are either at a safepoint for G1 or not for concurrent GCs.

           Service_lock(service) -> HeapRegionRemSet#n_lock(service-1)
                                                  -> FreeList_lock(should be service -1 now)

          StackWaterMark_lock(stackwatermark) -> Service_lock(service) for ServiceThread::oops_do_no_frames.

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                Created:
                Updated:
                Resolved: