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.