RFR: 8172751: OSR compilation at unreachable bci causes C1 crash
Andreas Woess
andreas.woess at oracle.com
Mon Jan 16 01:53:17 UTC 2017
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,
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