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

[Chris Plummer]

On Fri, 10 Oct 2025 19:52:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
>> 
>> 
>> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
>> 
>> 
>> And also I got following (strange) stacks which causes `AssersionFailure` in above:
>> 
>> 
>> ----------------- 70094 -----------------
>> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
>> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
>> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
>> 0x00007f8f646bb14e __sleep + 0x3e
>> 0x00007f8f4b3a8e1e <nep_invoker_blob>
>> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(...
>
> 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.ForkJoinPool.runWorker(java.util.concurrent.F...

> @plummercj Did you run `jhsdb jstack --mixed` ? StubRoutine would appear in mixed mode only I think (in Linux, at least).

I did not, and unfortunately --mixed is not support on OSX.

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

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