RFR: 8343244: Aarch64: Internal Error virtualMemoryTracker.cpp:444 assert(reserved_rgn != nullptr) failed: Add committed region, No reserved region found [v4]

[Coleen Phillimore]

On Wed, 6 Nov 2024 16:12:49 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> Ping @roberttoyonaga , @tstuefe , @afshin-zafari , @dholmes-ora , @gerard-ziemski
>> 
>> We are seeing issues with the transition to one of our 'fat' mutexes. Specifically, we do have `os::commit_memory` that occurs during the running `Thread`'s initialization, see the following stack trace:
>> 
>> 
>> Stack: [0x0000ffff686ae000,0x0000ffff687ae000], sp=0x0000ffff687ac5f0, free space=1017k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V [libjvm.so+0x16aa67c] VirtualMemoryTracker::add_committed_region(unsigned char*, unsigned long, NativeCallStack const&)+0x38c (virtualMemoryTracker.cpp:444)
>> V [libjvm.so+0x131134c] os::commit_memory(char*, unsigned long, bool)+0x198 (memTracker.hpp:165)
>> V [libjvm.so+0x14ddf54] StackOverflow::create_stack_guard_pages()+0x70 (stackOverflow.cpp:97)
>> V [libjvm.so+0xe2e0dc] attach_current_thread.isra.0+0x11c (jni.cpp:3809)
>> C [libExplicitAttach.so+0xa64] thread_main+0x34 (libExplicitAttach.c:45)
>> C [libc.so.6+0x806b8] start_thread+0x2d8
>> 
>> 
>> This, in turn, causes issues where the lock isn't actually taken, causing issues with the VMT. I'd like to suggest that we switch out the `Mutex` to a `PlatformMutex`. Platform mutexes are identical in construction to `ThreadCritical`, but are at least not shared globally and can be owned by the `VirtualMemoryTracker`.
>> 
>> If you do not agree with this change, then I suggest that we back out [8304824](https://bugs.openjdk.org/browse/JDK-8304824) ASAP and wait for a better solution.
>> 
>> Thanks.
>
> Johan Sjölen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   That assert is clearly incorrect

I don't think you should use PlatformMutex in the raw in runtime code (some GC code does use it) - if Mutex is not yet initialized, use ConditionalMutex instead.  Yes, PlatformMutex doesn't have the deadlock detection which you'll want with NMT code (other locks are being held when you take out NMT locks so verifying rank is important), and it also has no-safepoint checking since you'll want these locks to not check for a safepoint.

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

PR Comment: https://git.openjdk.org/jdk/pull/21928#issuecomment-2463331535