On Sat, 7 Mar 2026 00:13:12 GMT, Chris Plummer <[email protected]> wrote:

>> We saw the failure in serviceability/sa/TestJhsdbJstackMixedWithXComp.java 
>> on Valhalla repo. `jhsdb jstack --mixed` could not unwind continuation call 
>> frames as following:
>> 
>> 
>>                    * LingeredAppWithVirtualThread.run() bci:15 line:69 
>> (Interpreted frame)
>>                    * java.lang.Thread.runWith(java.lang.Object, 
>> java.lang.Runnable) bci:5 line:1540 (Compiled frame [deoptimized]; 
>> information may be imprecise)
>>                    * java.lang.VirtualThread.run(java.lang.Runnable) bci:62 
>> line:472 (Compiled frame [deoptimized]; information may be imprecise)
>> 0x00007fdad773cf98 <StubRoutines (continuation stubs)>
>> 0xfefefefefefefefe ????????
>> 
>> 
>> I found that `frame::sender_for_compiled_frame()` in frame_x86.inline.hpp 
>> has a special case if sender PC has return barrier entry, but SA does not 
>> handle it.
>> 
>> This is not only a problem on Valhalla. Same problem exists on JDK. So I 
>> want to fix on JDK.
>> This PR passed serviceability/sa tests on Linux, and also 
>> TestJhsdbJstackMixedWithXComp.java on Valhalla passed 100 times.
>> 
>> This PR is assembled by following commits:
>> 
>> * Follows continuation-related code in HotSpot, and use it on AMD64 SA code
>>     * 
>> https://github.com/openjdk/jdk/pull/30107/changes/4af559ee0dbc0bb61e0bcd91bb17459a5abf50ad
>> * Fix for AArch64
>>     * 
>> https://github.com/openjdk/jdk/pull/30107/changes/2cff0fe40c52b88dd8d79ad1534e73b7b0f88f8d
>> * Fix for RISC-V
>>     * 
>> https://github.com/openjdk/jdk/pull/30107/changes/fdef0384577bb71d34371f11bc5878494f276857
>> * Fix for PPC64
>>     * 
>> https://github.com/openjdk/jdk/pull/30107/changes/5d9774d82c7e8c4d92eae8995ab014232ce9590e
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Continuation.java 
> line 41:
> 
>> 39:     public static boolean isSPInContinuation(ContinuationEntry entry, 
>> Address sp) {
>> 40:         return entry.getEntrySP().greaterThan(sp);
>> 41:     }
> 
> This could be made private.

It is public member in HotSpot, so I aligned with it. However it does not need 
to be public in SA.
Should we it to be private?

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Continuation.java 
> line 43:
> 
>> 41:     }
>> 42: 
>> 43:     public static ContinuationEntry getContinuationEntryForSP(JavaThread 
>> thread, Address sp) {
> 
> This also could be made private.

It is public member in HotSpot, so I aligned with it. However it does not need 
to be public in SA.
Should we it to be private?

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64Frame.java
>  line 282:
> 
>> 280:     //     _chunk = 
>> stackChunkHandle(Thread::current()->handle_area()->allocate_null_handle(), 
>> true /* dummy */);
>> 281:     //   }
>> 282: 
> 
> I don't understand how this comment is relevant to the code below. Why is 
> this here?

SA should follow HotSpot implementation, so that code should be included 
basically. However it is not needed in this case. Thus I left comment the 
reason.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/30107#discussion_r2898900222
PR Review Comment: https://git.openjdk.org/jdk/pull/30107#discussion_r2898900710
PR Review Comment: https://git.openjdk.org/jdk/pull/30107#discussion_r2898896696

Reply via email to