RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux

[Yasumasa Suenaga]

On Fri, 10 Oct 2025 20:38:51 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> I applied the changes to AARCH64Frame.java and they seem to fix the issue with the exception. I'm seeing two different stack traces (see below), and neither is identical to your fixed stack trace. I don't see `<StubRoutines (continuation stubs)>`. Instead I see a frame for `jdk.internal.vm.Continuation.enterSpecial()`. Also, I don't see `<StubRoutines (initial stubs)>` or any of the frames that come after it. Maybe these are just expected platform differences.
>> 
>> "ForkJoinPool-1-worker-5" #34 daemon prio=5 tid=0x0000000159051c10 nid=34819 runnable [0x0000000172761000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>>  - java.lang.invoke.LambdaForm$MH+0x000003fe01047000.invoke(java.lang.Object, long, int) @bci=10 (Interpreted frame)
>>  - java.lang.invoke.LambdaForm$MH+0x000003fe01054800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) @bci=21 (Interpreted frame)
>>  - jdk.internal.foreign.abi.DowncallStub+0x000003fe01048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame)
>>  - java.lang.invoke.LambdaForm$DMH+0x000003fe01048400.invokeStaticInit(java.lang.Object, java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame)
>>  - java.lang.invoke.LambdaForm$MH+0x000003fe0104f400.invoke(java.lang.Object, int) @bci=44 (Interpreted frame)
>>  - java.lang.invoke.LambdaForm$MH+0x000003fe0104e400.invoke_MT(java.lang.Object, int, java.lang.Object) @bci=18 (Interpreted frame)
>>  - Test.run() @bci=21, line=28 (Interpreted frame)
>>  - jdk.internal.vm.Continuation.enterSpecial(jdk.internal.vm.Continuation, boolean, boolean) @bci=0 (Compiled frame)
>>  - jdk.internal.vm.Continuation.run() @bci=152, line=251 (Interpreted frame)
>>  - java.lang.VirtualThread.runContinuation() @bci=100, line=293 (Interpreted frame)
>>  - java.lang.VirtualThread$$Lambda+0x000003fe01027670.run() @bci=4 (Interpreted frame)
>>  - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=4, line=1753 (Interpreted frame)
>>  - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=1, line=1745 (Interpreted frame)
>>  - java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() @bci=51, line=1662 (Interpreted frame)
>>  - java.util.concurrent.ForkJoinTask.doExec() @bci=10, line=511 (Interpreted frame)
>>  - java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) @bci=5, line=1450 (Interpreted frame)
>>  - java.util.concurrent.F...
>
>> I applied the changes to AARCH64Frame.java and they seem to fix the issue with the exception. I'm seeing two different stack traces (see below), and neither is identical to your fixed stack trace. I don't see `<StubRoutines (continuation stubs)>`. Instead I see a frame for `jdk.internal.vm.Continuation.enterSpecial()`. Also, I don't see `<StubRoutines (initial stubs)>` or any of the frames that come after it. Maybe these are just expected platform differences.
>>
> These two different stack traces are expected and depend on whether the vthread was unmounted or not. With the current test this is timing dependent. You can run the test commenting out the `System.out.println` call, and then again replacing it with `Thread.yield()`. The string `<StubRoutines (continuation stubs)>` does look like from a previous version though. Even on x64 I see the `enterSpecial` frame printed out, and it matches what I would expect based on the patch.

@pchilano I reproduce the problem with `Thread.yield()`. Thanks! So I added test in the latest commit. I believe it works on both AMD64 and AArch64.

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

PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3393398658