RFR(XXS): 8212928: Assertion too strict in compiledVFrame::update_deferred_value() on SPARC

[Reingruber, Richard]

Thank you Vladimir.

Regards, Richard.

-----Original Message-----
From: Vladimir Kozlov <vladimir.kozlov at oracle.com> 
Sent: Donnerstag, 8. November 2018 02:24
To: Reingruber, Richard <richard.reingruber at sap.com>; hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR(XXS): 8212928: Assertion too strict in compiledVFrame::update_deferred_value() on SPARC

Hi Richard,

Change seems fine but I will run full testing to very it and the test.

Regards,
Vladimir

On 10/25/18 12:58 AM, Reingruber, Richard wrote:
> Hi,
> 
> 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.
>