[9] RFR(S/M): 8166377: is_compiled_by_jvmci hot in some profiles - improve nmethod compiler type detection

[Nils Eliasson]

Yes, instant include hell. See my answer to Christian.

Regards,
Nils

On 2016-10-04 20:01, Vladimir Kozlov wrote:
> Can we move CompLevel, CompilerType and related code to 
> abstractCompiler.hpp? Some #include dependencies may no allow it but 
> we should try.
>
> It is strange to have it in globalDefinitions.hpp.
>
> Otherwise changes are good.
>
> Thanks,
> Vladimir
>
> On 10/4/16 6:54 AM, Nils Eliasson wrote:
>>
>> Hi,
>>
>> Please review this change. It touches many files but is not complex.
>>
>> Description:
>> We have seen a performance regression in some benchmarks where
>> nmethod::is_compiled_by_jvmci() has been hot. That method is used is a
>> workaround in CompiledMethod::is_deopt_entry(). The workaround remains
>> for the moment, this fix makes it less costly.
>>
>> Summary:
>> This fix removes the compiler reference from the codeblobs and instead
>> performs the compiler type check on a constant, this removes a double
>> dereference when checking the compiler. I also took the time to properly
>> add the compiler types to the constructors.
>>
>>
>> bugs: https://bugs.openjdk.java.net/browse/JDK-8166377
>> webrev: http://cr.openjdk.java.net/~neliasso/8166377/
>>
>> Regards,
>> Nils Eliasson