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