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

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Nov 8 17:04:57 UTC 2018

Testing passed and I pushed it:



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.

More information about the hotspot-compiler-dev mailing list