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

[Nils Eliasson]

Putting them in abstract compiler caused an include hell, and all the 
comp level defintions where already in globalDefinitions (probably by 
the same reason).

I'll give it a second try putting them in abstractCompiler. One other 
alternative is having a separate compilerDefinitions file.

Regards,
Nils

On 2016-10-04 19:11, Christian Thalinger wrote:
>
>> On Oct 4, 2016, at 3:54 AM, Nils Eliasson <nils.eliasson at oracle.com 
>> <mailto:nils.eliasson at oracle.com>> 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/ 
>> <http://cr.openjdk.java.net/%7Eneliasso/8166377/>
>
> I don’t like that all the CompilerType stuff is now in 
> globalDefinitions.  Why did you move it there?
>
>>
>> Regards,
>> Nils Eliasson
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20161005/6d538107/attachment.html>