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

[Reingruber, Richard]

Thanks again!
Richard.

-----Original Message-----
From: Vladimir Kozlov <vladimir.kozlov at oracle.com> 
Sent: Thursday, November 8, 2018 6:05 PM
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

Testing passed and I pushed it:

http://hg.openjdk.java.net/jdk/jdk/rev/6954394aa33a

Vladimir

On 11/8/18 12:09 AM, Reingruber, Richard wrote:
> 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.
>>