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

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Jul 22 16:18:49 UTC 2014


Perfect.

Thanks,
Vladimir

On 7/22/14 8:22 AM, Filipp Zhinkin wrote:
> 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