RFR: 8356173: Remove ThreadCritical

Thomas Stuefe stuefe at openjdk.org
Fri May 9 06:51:52 UTC 2025


On Fri, 9 May 2025 04:58:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Updated the description in the bug.  This removes the last use of ThreadCritical and replaces it with a global PlatformMutex lock.
>> Tested with tier1-4, and tier1 on all Oracle-supported OSs.
>
> src/hotspot/share/memory/arena.cpp line 47:
> 
>> 45: void Arena::initialize_chunk_pool() {
>> 46:   _global_chunk_pool_mutex = new PlatformMutex();
>> 47: }
> 
> Possibly a candidate for @jdksjolen 's `Deferred<T>`?

Why do we even need dynamic initialization here? I thought that is the tradeoff with PlatformMutex: you forego deadlock checks etc, but you gain safety wrt initialisation.
That would also save some instructions.

> src/hotspot/share/runtime/threads.cpp line 463:
> 
>> 461: 
>> 462:   // Initialize memory pools
>> 463:   Arena::initialize_chunk_pool();
> 
> What code first uses a `ChunkPool` or the `ChunkPoolLocker`? (It isn't obvious at what point the NMT code may execute during early initialization.)

Any Arena that is created allocates an initial chunk. Arenas are created during (any) Thread creation, for compiler initialization and in universe::init, among others. So this is needed early.

But as I wrote above, I don't think we need dynamic initialization at all?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25072#discussion_r2081004650
PR Review Comment: https://git.openjdk.org/jdk/pull/25072#discussion_r2080987856


More information about the hotspot-dev mailing list