RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86
David Holmes
dholmes at openjdk.java.net
Sat Apr 17 05:40:36 UTC 2021
On Fri, 16 Apr 2021 22:50:39 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:
> `trace_method_handle_stub` on x86 tries to dump the frame which initiated the tracing, but fails to find the proper frame when it is the immediate caller.
>
> The problem is `os::current_frame()` returns the caller (instead of the current frame as the name suggests) and then `os::get_sender_for_C_frame()` steps over one more frame. So, if there are no intermediate frames present, it steps over the desired frame.
>
> Proposed fix is to start the search from the frame reported by `os::current_frame()`.
>
> Testing:
> - [x] failing test
> - [x] hs-precheckin-comp,hs-tier1,hs-tier2 w/ `-Xlog:methodhandles=trace`
Hi Vladimir,
Based on the problem description the solution seems correct, but as mentioned offline I'm always concerned that the correct use of "current frame" can depend on the presence or absence of inlining. So it is never clear to me that changes like this do not simply switch the set of contexts where this code is correct, based on the problem being solved today.
Thanks,
David
src/hotspot/cpu/x86/methodHandles_x86.cpp line 558:
> 556: FrameValues values;
> 557:
> 558: frame cur_frame = os::current_frame(); // reports caller's frame!
It is unclear what "caller" is relative to in that comment - is it the caller of os::current_frame() as seen by os::current_frame(), or is it the caller of the current method that is invoking os::current_frame() ?
-------------
Marked as reviewed by dholmes (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/3554
More information about the hotspot-runtime-dev
mailing list