RFR: 8244920: Access violation in frames::interpreter_frame_method
markus.gronlund at oracle.com
Mon Jun 8 14:01:03 UTC 2020
Here is my understanding of this situation:
The thread's last java frame (_anchor._last_Java_sp) is already set when the thread enters Deoptimization::uncommon_trap(), pointing to the "UncommonTrapBlob", but the stack is still parsable / walkable.
In fact, a lot of the comments in the code assert the stack to be walkable during most of the unpacking process, for example in AbstractInterpreter::layout_activation():
"// It is also guaranteed to be walkable even though it is in a skeletal state"
At least it asserts this before it starts to perform the modifications to the frame.
Since the thread is in thread state "thread_in_Java", I would say this issue indicate a more general problem, affecting other profilers as well, for example users of AsynchGetCallTrace.
Your suggestion, although it will work, could have an impact on profilers in that they will not get as many samples as they have got previously (because we've disabled the stack walking during unpacking).
Perhaps it would be possible to solve this by doing something like:
What if we hoist the read of the mirror to before the frame starts to mutate, for example in AbstractInterpreter_x86.cpp:
assert(caller->sp() == interpreter_frame->sender_sp(), "Frame not properly walkable");
81 oop mirror = method->method_holder()->java_mirror() <<--- TO HERE
Instead of doing late at a time where the frame has already started to mutate ( currently the mirror is read at line 117). Could this maybe be a solution that keeps the stack walkable?
Do we know the exact failure, i.e. why the stack is not parsable at line 117?
From: Erik Österlund
Sent: den 8 juni 2020 09:15
To: Hotspot dev runtime <hotspot-runtime-dev at openjdk.java.net>
Cc: Markus Gronlund <markus.gronlund at oracle.com>; Erik Gahlin <erik.gahlin at oracle.com>
Subject: RFR: 8244920: Access violation in frames::interpreter_frame_method
When we unpack interpreter frames due to deoptimization, we find ourselves in a situation where the stack space has been allocated, and the last_Java_frame has been set, but the contents of the frames has not yet been populated. Any JFR event firing during this time will think the stack can be parsed, as the last_Java_frame has been set, and then fail doing so, when running into uninitialized stack frames. After ZGC added an event that sometimes fires in load barriers, we suddenly found ourselves in this awkward spot.
I propose to clear the last_Java_frame after the top frame has been acquired, and is no longer needed during the unpacking, so that such events will see that we are in fact in a leaf call and should not attempt to sample the stack.
More information about the hotspot-runtime-dev