RFR: 8369622: GlobalChunkPoolMutex needs to be recursive

Zhengyu Gu zgu at openjdk.org
Mon Oct 13 14:21:55 UTC 2025


On Mon, 13 Oct 2025 06:38:31 GMT, David Holmes <dholmes 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.
>
> src/hotspot/share/memory/arena.cpp line 55:
> 
>> 53:       PlatformMutex::lock();
>> 54:       _owner = t;
>> 55:     }
> 
> As per the comment:
> 
> // For many calls, the current thread has not
> // been created so we cannot use Mutex.
> 
> this ownership test won't allow for recursive use in those circumstances. So we have slightly odd semantics here that the mutex is recursive for attached threads but not for un-attached. For this specialised usecase maybe we can tolerate that.

What if the lock is contended by two threads without `current thread`s?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27759#discussion_r2426493709


More information about the hotspot-runtime-dev mailing list