RFR(S): 8154151: VM crashes with assert "Ensure we don't compile before compilebroker init"

Nils Eliasson nils.eliasson at oracle.com
Fri Apr 15 13:30:29 UTC 2016


I forgot the link to the test job:

This is both for this and JDK-8153013 BlockingCompilation test times out
https://jdash.se.oracle.com/rbt/rbt-nils.eliasson-compiler_control-20160415-1309-10848

Regards,
//Nils

On 2016-04-15 01:41, Vladimir Kozlov wrote:
> I agree with this simple change as the fix.
> Note, -Xcomp does not switch off Interpreter (we can run without 
> Interpreter). We use !UseInterpreter as indication if Xcomp was used.
> I don't see a PIT link in the bug report.
>
> Thanks,
> Vladimir
>
> On 4/14/16 6:17 AM, Nils Eliasson wrote:
>> Hi,
>>
>> Please review this fix.
>>
>> Summary:
>> In JDK-8150646 I added an assert in compile_method that the compiler 
>> must not be NULL. Before there was a return there that just ignored 
>> the compile.
>>
>> Running the VM with the flag combination -Xcomp and 
>> -XX:TieredStopAtLevel=0 creates a special situation: UseInterpreter 
>> is set to false (but the interpreter it is still available) and then 
>> some
>> essential methods are forced to be compiled, but the initial 
>> complevel becomes 0 and hits the assert in compileBroker.
>>
>> Solution:
>> We could discuss if it should be allowed to submit compiles on level 
>> 0, a change that would become a bit larger. This time I choose to 
>> extend the _initalized check in compile_method. I didn't add any
>> logging or warning because this is really a corner case.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154151
>> Webrev: http://cr.openjdk.java.net/~neliasso/8154151/webrev.01/
>> (Ignore the extra tags in the webrev)
>>
>> Best regards,
>> Nils Eliasson



More information about the hotspot-compiler-dev mailing list