RFR: 8172751: OSR compilation at unreachable bci causes C1 crash

[Tobias Hartmann]

Hi Andreas,

I'll sponsor your change (I did some testing and the results look good).

Best regards,
Tobias

On 16.01.2017 09:16, Tobias Hartmann wrote:
> Hi Andreas,
> 
> On 16.01.2017 02:53, Andreas Woess wrote:
>> Hi Tobias,
>>
>> I've updated the test and added a comment to make it clearer.
>>
>> We enter the first loop, where we flip the outer if's condition to make
>> the branch we're in unreachable, but continue in the first loop until
>> it's OSR-compiled. C1 then skips the now seemingly unreachable first
>> loop and doesn't visit the OSR entry point.
> 
> Thanks, it's clearer now. Looks good to me!
> 
> Best regards,
> Tobias
> 
>>
>> Thanks,
>> Andreas
>>
>> On 2017-01-13 10:54, Tobias Hartmann wrote:
>>> Hi Andreas,
>>>
>>> On 13.01.2017 05:04, Andreas Woess wrote:
>>>> Hi all,
>>>>
>>>> please review the following patch:
>>>> http://cr.openjdk.java.net/~aw/8172751/webrev/
>>>> https://bugs.openjdk.java.net/browse/JDK-8172751
>>>>
>>>> This is a small fix for a extremely unlikely but consistently
>>>> reproducible crash (see included test) in the C1 GraphBuilder with OSR.
>>>> AFAICT, the problem is that we may never visit the osr entry block if
>>>> it's found to be unreachable during parsing due to constant folding.
>>>>
>>>> The patch simply changes the existing assertion to a bailout. We'd crash
>>>> immediately after it trying to get the osr block's state (in a product
>>>> build; in a debug build the assertion fails).Observed on JDK 8u* and 9.
>>> This looks reasonable to me!
>>>
>>> Could you please provide some more information on how the test case works? I guess we trigger OSR compilation in the first loop of executeLoop() and then make the branch unreachable during compilation by calling flipSwitch(), right? Maybe add some comments to the test.
>>>
>>> Thanks,
>>> Tobias
>>>
>>>> Thanks,
>>>> Andreas
>>>>
>>