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

redo nested ThreadsListHandle to drop Threads_lock

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 10
    • Fix Version/s: 11
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b12
    • CPU:
      generic
    • OS:
      generic

      Description

      A code review comment from Stefan K about nested
      ThreadsListHandles using the Threads_lock:

      1) ThreadsListHandle allows a safepoint to block and allow GCs to run and restructure objects and metadata, iff the ThreadsListHandle is nested. This forced me to review all usages of ThreadsListHandle in great detail to visually verify that it didn't break the surrounding code.

      If ThreadsListHandle didn't ever block for safepoints, I wouldn't have had to care about that aspect when reading and reviewing the code. This also means that we in the future runs the risk of someone accidentally adding a nested ThreadsListHandle somewhere where they don't expect a safepoint to happen.

      If the lock protecting the threads list could be taken with no_safepoint_check, then the described problem above would completely vanish. Unfortunately, we can't acquire the Threads_lock with no_safepoint_check. A solution to this would be to introduced a low-rank (rank == access) lock, say ThreadsList_lock, and always take it with no_safepoint_check.

      That solution would also solve a potential lock-rank problem, we have that ThreadsListHandle can't be used if a higher-rank lock is held.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                dcubed Daniel Daugherty
                Reporter:
                dcubed Daniel Daugherty
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: