RFR(S): 8051344: JVM crashed in Compile::start() during method parsing w/ UseRTMDeopt turned on

Filipp Zhinkin filipp.zhinkin at oracle.com
Tue Jul 22 15:22:45 UTC 2014


Hi Vladimir,

thank you for looking at it.

I've updated fix so now rtm_deopt called only if there were no bailouts
and after that failing() state is checked.

Updated webrev: http://cr.openjdk.java.net/~fzhinkin/8051344/webrev.01/

Thanks,
Filipp.

On 07/21/2014 10:13 PM, Vladimir Kozlov wrote:
> The original placement was done in assumption that rtm_deopt() may 
> also produce failing() state. But looking through methods it uses it 
> may not treu. So moving it after failing() check without adding an 
> other check after it seems fine but please verify.
>
> Otherwise it look good.
>
> Thanks,
> Vladimir
>
> On 7/21/14 10:27 AM, Filipp Zhinkin wrote:
>> Hi all,
>>
>> please review fix for JDK-8051344.
>>
>> Original issue is about misplaced Parse::rtm_deopt call:
>> it was done between method entry setup and check for bailouts during
>> that setup.
>>
>> As a result, when rtm_deopt was called after bailout it either crashed
>> while
>> tryingto access start block (which is NULL after Compile::record_failure
>> call)
>> or failed on assert inside Compile::start.
>>
>> Fix is trivial: rtm_deopt call was placed after bailouts check.
>>
>> I've also added new test that cause OSR bailout due to non-empty
>> interpreter stack.
>>
>> JBS issue: https://bugs.openjdk.java.net/browse/JDK-8051344
>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8051344/webrev.00/
>> Testing: JPRT, manual on host w/ Haswell CPU
>>



More information about the hotspot-compiler-dev mailing list