RFR(XXS): 8212928: Assertion too strict in compiledVFrame::update_deferred_value() on SPARC
vladimir.kozlov at oracle.com
Thu Nov 8 01:23:52 UTC 2018
Change seems fine but I will run full testing to very it and the test.
On 10/25/18 12:58 AM, Reingruber, Richard wrote:
> 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
> native call.
> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/2018/8212928/webrev.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8212928
> The contribution needs to be sponsored as well.
> Thanks, Richard.
> 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