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

[Vladimir Ivanov]

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`

Thanks for the review, David.

> 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.

In this particular case, `trace_method_handle_stub` is always called from generated code which sets up the frame being looked for. So, irrespective of the decisions being made by the native compiler, if there's enough info to traverse the native stack, the proper frame will be found.    

As an alternative solution, the code can be migrated away from `os::current_frame()` and the caller be obliged to pass stack frame info as an argument instead.

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

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