RFR(XXS): 8212928: Assertion too strict in compiledVFrame::update_deferred_value() on SPARC
richard.reingruber at sap.com
Thu Oct 25 07:58:19 UTC 2018
could I please get reviews for the following small patch? It relaxes the assertion in
compiledVFrame::update_deferred_value() about is_deoptimized_frame() returning true for the
underlying physical frame.
The included test shows that the assertion is too strict, because for NeedsDeoptSuspend (e.g. on
SPARC) there is a special case in frame::deoptimize(). If the owner of this frame is currently in
native code and this frame is the caller of the native method, then the deoptimization is not done
synchronously for the requesting thread. Instead the owner thread does it when returning from the
The contribution needs to be sponsored as well.
PS: In the first place I looked at the assertion, because I didn't like that
after calling frame::deoptimize() the requesting java thread has to walk the
stack again to get a frame object that reflects the correct
frame::_deopt_state. But (a) I couldn't find a nice solution, and (b) I'm not
sure, if it is safe in general to use a stale frame object.
More information about the hotspot-compiler-dev