[jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v3]

David Holmes dholmes at openjdk.java.net
Thu Jul 15 23:00:29 UTC 2021


On Thu, 15 Jul 2021 11:02:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> How does native code reach a safepoint polling point?
>
> The stack trace looks like this:
> 
> 
> Current thread (0x000002a2489f0b50):  JavaThread "Thread-4551" [_thread_in_Java, id=24920, stack(0x000000d9e0500000,0x000000d9e0600000)]
> 
> Stack: [0x000000d9e0500000,0x000000d9e0600000]
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [jvm.dll+0xae6651]  os::platform_print_native_stack+0xf1  (os_windows_x86.cpp:235)
> V  [jvm.dll+0xda3f25]  VMError::report+0x1005  (vmError.cpp:739)
> V  [jvm.dll+0xda58ae]  VMError::report_and_die+0x7fe  (vmError.cpp:1549)
> V  [jvm.dll+0xda5fe4]  VMError::report_and_die+0x64  (vmError.cpp:1330)
> V  [jvm.dll+0x4ceca7]  report_vm_error+0xb7  (debug.cpp:282)
> V  [jvm.dll+0x6511be]  HandleArea::allocate_handle+0x3e  (handles.cpp:35)
> V  [jvm.dll+0xb8e334]  ThreadSafepointState::handle_polling_page_exception+0x314  (safepoint.cpp:939)
> C  0x000002a035d8caa7
> 
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> v  ~SafepointBlob
> J 639 c1 java.lang.invoke.LambdaForm$MH+0x000000080101b800.invoke(Ljava/lang/Object;)V java.base at 18-internal (87 bytes) @ 0x000002a03635f7b4 [0x000002a03635f4a0+0x0000000000000314]
> J 620 c1 java.lang.invoke.LambdaForm$MH+0x0000000801018c00.invoke(Ljava/lang/Object;)V java.base at 18-internal (37 bytes) @ 0x000002a036353e0c [0x000002a036353720+0x00000000000006ec]
> v  ~BufferBlob::mэYссссЫGў
> 
> 
> So I think the 'native code' is something being called by the safepoint blob, but I'm not sure why it's marked with a `C` instead of `V` in the stack trace (maybe just a stack unwind failure?).
> 
> FWIW, this part has already been fixed as part of: https://github.com/openjdk/jdk17/pull/173 (not sure why it still shows up in the diff)

Okay so we're not actually _thread_in_native it is just a chunk of VM generated code. Something still seems off to me about the need for the HandleMark but that isn't your problem.

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

PR: https://git.openjdk.java.net/jdk17/pull/149


More information about the core-libs-dev mailing list