On Fri, 10 Oct 2025 20:38:51 GMT, Patricio Chilano Mateo <[email protected]> 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
