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

Thomas Stuefe stuefe at openjdk.org
Wed Nov 6 16:29:34 UTC 2024


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 believe the problem is not in stack guard creation, but in these two lines in attach_current_thread:

> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();

They should be reversed. I would guess that would solve the problem. 

But for now, I would probably prefer to back out the patch and think a bit. Changing to PlatformMutex would deny us deadlock detection, right?

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

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


More information about the hotspot-dev mailing list