RFR: 8304824: NMT should not use ThreadCritical

Robert Toyonaga duke at openjdk.org
Sat Sep 7 17:33:40 UTC 2024


On Thu, 5 Sep 2024 21:10:27 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.  `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've implemented the new lock with a semaphore so that it can be used early before VM init.  There is also the possibility of adding assertions in places we expect NMT to have synchronization. I haven't added assertions yet in many places because some code paths such as the (NMT tests)  don't lock yet. I think it makes sense to close any gaps in locking in another PR in which I can also add more assertions. 
>> 
>> Testing:
>> - hotspot_nmt
>> - gtest:VirtualSpace
>> - tier1
>
> The GHA `macos-aarch64 / test - Test (tier1) `  is failing due to `TEST: runtime/cds/DeterministicDump.java`  with the message `java.lang.RuntimeException: File content different at byte #4, b0 = -126, b1 = -52`. 
> But I don't think it's related to the changes in this PR.  It also looks like this test is failing on other recent PRs.

> @roberttoyonaga Why don't we use a normal hotspot mutex here?

Hi @tstuefe. I tried using a regular mutex along with `MutexLocker`, but it seems like the mutex isn't initialized early enough to be used during VM init. After building I get: 

`assert(NMT_lock != nullptr) failed: not initialized!`


Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x178448c]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x948  (nmtCommon.hpp:137)
V  [libjvm.so+0x1783aed]  (vmError.cpp:1611)
V  [libjvm.so+0xa8e2d2]  report_vm_status_error(char const*, int, char const*, int, char const*)+0x0  (debug.cpp:193)
V  [libjvm.so+0x8cb317]  NMTUtil::nmt_lock()+0x69  (nmtCommon.hpp:137)
V  [libjvm.so+0x13a0459]  MemTracker::record_virtual_memory_reserve(void*, unsigned long, NativeCallStack const&, MEMFLAGS)+0x36  (memTracker.hpp:128)
V  [libjvm.so+0x139d292]  os::reserve_memory(unsigned long, bool, MEMFLAGS)+0x80  (os.cpp:1877)
V  [libjvm.so+0xa8fc31]  initialize_assert_poison()+0x1f  (debug.cpp:712)
V  [libjvm.so+0x16e5720]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x1be  (threads.cpp:489)
V  [libjvm.so+0xf62555]  JNI_CreateJavaVM_inner(JavaVM_**, void**, void*)+0xbd  (jni.cpp:3582)
V  [libjvm.so+0xf629e3]  JNI_CreateJavaVM+0x32  (jni.cpp:3673)
C  [libjli.so+0x8c04]  InitializeJVM+0x14d  (java.c:1592)
C  [libjli.so+0x5337]  JavaMain+0xe8  (java.c:505)
C  [libjli.so+0xc61e]  ThreadJavaMain+0x27  (java_md.c:653)
C  [libc.so.6+0x97507]  start_thread+0x377

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

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2336137156


More information about the serviceability-dev mailing list