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

[Vladimir Ivanov]

On Mon, 19 Apr 2021 21:07:24 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> It's always difficult to document a call to `os::current_frame()`.
>> I ran into this all the time when working with `AsyncGetCallTrace()`...
>> 
>> When I see the comment that you wrote here:
>> 
>> - I expect that comment to apply to the context in which I find that comment.
>> - In this case, I expect the `os::current_frame()` to return the caller's frame and since that comment is in `trace_method_handle_stub` AND that's the code that's calling `os::current_frame()`, I expect the "caller's frame" to mean `trace_method_handle_stub`.
>> 
>> If that's what you mean, then we're okay from my POV. If that's not what  you mean, then I'm confused.
>
> I can completely remove the comment. It turns out any reference to "current"/"caller"/"callee" doesn't make much sense.

Why I thought that explicitly calling that it's the "caller's frame" makes things clearer: 
  (1) the code explicitly is written in such a way to skip any intermediate frames;
  (2) all users are in generated code.

So, we know for sure there's a separate frame on the stack (which contains register values) and it differs from the top one. The bug is that we can't skip the frame returned by `os::current_frame()` because it doesn't return the top frame on the stack, but the next one.

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

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