RFR: 8356173: Remove ThreadCritical

[Coleen Phillimore]

On Fri, 9 May 2025 05:59:14 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> 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?

Yes, this is needed early.  We create the ResourceArea arena when creating a JavaThread before the JavaThread is completely created so Thread::current() doesn't exist in this case.  There are also other early initializations.

There's two things that make us unable to have a static PlatformMutex.  1. on macosx, the PlatformMutex is implemented using an indirection the macosx dll load crashes trying to initialize it.


#  assert(status == 0) failed: error EINVAL(22), freelist lock

V  [libjvm.dylib+0xea68c4]  PlatformMutex::PlatformMutex()+0xfc
V  [libjvm.dylib+0x269c34]  _GLOBAL__sub_I_arena.cpp+0x38
C  [dyld+0x22a24]  invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const::$_0::operator()() const+0xa8
C  [dyld+0x680f4]  invocation function for block in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const+0xac
C  [dyld+0x5b668]  invocation function for block in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const+0x1f0
C  [dyld+0x22fc]  dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const+0x12c
C  [dyld+0x5a6a0]  dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const+0xc0
C  [dyld+0x5d188]  dyld3::MachOFile::forEachInitializerPointerSection(Diagnostics&, void (unsigned int, unsigned int, bool&) block_pointer) const+0xa0
C  [dyld+0x67de8]  dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) 


Even if I disable the indirect PlatformMutex workaround for the macosx bug JDK-8218975, the underlying pthread_mutex is not initialized before this code uses it.


#  assert(status == 0) failed: error EINVAL(22), mutex_init


So I don't think PlatformMutex can be a static variable, which is why I initialize it early in vm startup.

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

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