RFR: 8172751: OSR compilation at unreachable bci causes C1 crash
Tobias Hartmann
tobias.hartmann at oracle.com
Mon Jan 16 08:16:33 UTC 2017
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
>>>
>
More information about the hotspot-compiler-dev
mailing list