I tried to get mixed thread dump of the application which runs virtual threads (see Test.java attached this ticket) 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(java.lang.Object, long, int) bci:10 (Interpreted frame)
0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c050800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Interpreted frame)
0x00007f8f4b33fe48 * jdk.internal.foreign.abi.DowncallStub+0x000000000c048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) bci:44 (Interpreted frame)
0x00007f8f4b33fe48 * java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.lang.Object, java.lang.Object, java.lang.Object, int) bci:14 (Interpreted frame)
0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c04e400.invoke(java.lang.Object, int) bci:44 (Interpreted frame)
0x00007f8f4b33fd00 * java.lang.invoke.LambdaForm$MH+0x000000000c04c400.invoke_MT(java.lang.Object, int, java.lang.Object) bci:18 (Interpreted frame)
0x00007f8f4b33fd00 * Test.run() bci:21 line:28 (Interpreted frame)
0x00007f8f4b33e098 <StubRoutines (continuation stubs)>
0x00007f8f4b33fd00 <interpreter> return entry points
0x00007f8f4b33fd00 <interpreter> return entry points
0x00007f8f4b33fd00 <interpreter> return entry points
0x00007f8f4b340206 <interpreter> return entry points
0x00007f8f4b33fe9a <interpreter> return entry points
0x00007f8f4b33fe9a <interpreter> return entry points
0x00007f8f4b33fe48 <interpreter> return entry points
0x00007f8f4b33fd00 <interpreter> return entry points
0x00007f8f4b33fd00 <interpreter> return entry points
0x00007f8f4b33fd00 <interpreter> return entry points
0x00007f8f4b3386fd <StubRoutines (initial stubs)>
0x00007f8f62bc0a7e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
0x00007f8f62bc11b3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
0x00007f8f62bc17bb JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0xab
0x00007f8f62d83a90 thread_entry(JavaThread*, JavaThread*) + 0xd0
0x00007f8f62c02806 JavaThread::thread_main_inner() + 0x256
0x00007f8f63865b57 Thread::call_run() + 0xb7
0x00007f8f632fc588 thread_native_entry(Thread*) + 0x128
0x00007f8f6464ff54 start_thread + 0x2e4
```

According to stack layout described in continuationFreezeThaw.cpp and stub implementation in `StubGenerator::generate_cont_thaw()` in stubGenerator_x86_64.cpp, we cannot calculate caller SP from `CodeBlob` for continuation stub. We need to restore SP from `_cont_entry` in `JavaThread`.

I saw this issue on Linux AMD64 and AArch64. I'm not sure but it might happen on other platforms.