RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86

Daniel D.Daugherty dcubed at openjdk.java.net
Mon Apr 19 20:06:04 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`

Sorry, this change isn't make sense to me yet.

src/hotspot/cpu/x86/methodHandles_x86.cpp line 565:

> 563:         // Assumes saved_regs comes from a pusha in the trace_calling_frame.
> 564:         assert(cur_frame.sp() < saved_regs, "registers not saved on stack ?");
> 565:         frame trace_calling_frame = cur_frame;

Since I'm expecting `cur_frame` to be `trace_method_handle_stub`,
the original code makes sense to me since I want the sender for
`trace_method_handle_stub`.

If `cur_frame` is not `trace_method_handle_stub`, then I definitely
don't understand the code at L558 so I definitely don't understand
the comment that you added either.

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

Changes requested by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3554


More information about the hotspot-runtime-dev mailing list