[10] RFR: 8183299: Improve inlining of CompiledMethod methods into frame::sender

[Vladimir Kozlov]

Claes,

Did you try to swap && conditions?:

   36     || (pc == (deopt_handler_begin() + 
NativeCall::instruction_size) && is_compiled_by_jvmci())

is_compiled_by_jvmci() could be cache miss and other check is false in 
all cases (until Graal is used as JIT).

Thanks,
Vladimir

On 7/3/17 7:41 AM, Claes Redestad wrote:
> <adding hotspot-runtime-dev since this patch now touches 
> frame.inline.hpp as well>
> 
> Hi,
> 
> I've reworked the patch to introduce a compiledMethod.inline.hpp instead 
> to break a
> circular dependency on code/nativeInstr.hpp on some platforms.
> 
> http://cr.openjdk.java.net/~redestad/8183299/hotspot.01/
> 
> An attempt to tease apart the include dependencies was made (Stefan 
> Karlsson has
> an almost working patch to clean things up significantly), but there is 
> currently a lot of
> code out there that includes frame.inline.hpp transitively which makes 
> it cumbersome
> to add this new include in any other place and still keep the linker happy.
> 
> Testing: JPRT
> 
> Thanks!
> 
> /Claes
> 
> On 06/30/2017 06:50 PM, Claes Redestad wrote:
>> Hi all,
>>
>> here's a startup optimization that turned out to also help the VM 
>> stack walking in general, including java exception throwing performance:
>>
>> Webrev: http://cr.openjdk.java.net/~redestad/8183299/hotspot.00/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8183299
>>
>> The static footprint cost of the more aggressive inlining is ~20Kb, 
>> which seems reasonable for the achieved speed-up (~5% in some 
>> microbenchmarks).
>>
>> Testing: JPRT (still in-flight), jtreg locally, microbenchmarks
>>
>> Thanks!
>>
>> /Claes
>