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

[Filipp Zhinkin]

Vladimir,

thank you for the review.

FIlipp.

On 07/22/2014 08:18 PM, Vladimir Kozlov wrote:
> 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
>>>>
>>