RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v2]

[David Holmes]

On Wed, 15 Oct 2025 17:05:41 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

>> The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this.
>> 
>> This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented.
>> 
>> Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters.
>
> Johan Sjölen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Recur again!

I'm unclear if this particular lock will only encounter a null thread during VM init, or whether it can also be encountered during thread attach? If the former and we really don't need mutual exclusion when the thread is null, then a `ConditionalMutexLocker` might help with that aspect and we could go back to using `Thread::current()`. If `RecursiveMutex` were actually a `Mutex` then we might have been able to use it in conjunction with a `ConditionalMutexLocker`. Otherwise this custom implementation seems okay to me now.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27759#pullrequestreview-3343446645