RFR: 8221542: ~15% performance degradation due to less optimized inline decision

Jie Fu fujie at loongson.cn
Wed Apr 17 08:01:13 UTC 2019


Cool!
I'd like to spend some time to study your patch.
Thanks Vladimir.

On 2019/4/17 下午3:33, Vladimir Ivanov wrote:
> Though I don't consider parallel execution case as problematic,
> I got a better idea while browsing the code :-)
>
>   http://cr.openjdk.java.net/~vlivanov/jiefu/8221542/webrev.01
>
> It's inspired by AbstractInterpreter::is_not_reached() and piggybacks 
> on constant pool entry resolution state to determine whether a call 
> was executed in interpreter before.
>
> (The change in cpCache.cpp fixes a latent bug in 
> ConstantPoolCacheEntry::method_if_resolved().)
>
> Best regards,
> Vladimir Ivanov
>
> On 11/04/2019 19:27, Jie Fu wrote:
>> Hi Vladimir,
>>
>>>> Fixed in 
>>>> http://cr.openjdk.java.net/~jiefu/monte_carlo-perf-drop/webrev.03/
>>>
>>> I like it. What do you think about the following version?
>>>
>>> http://cr.openjdk.java.net/~vlivanov/jiefu/8221542/webrev.00/
>> It is more clearer and easier to understand.
>> I prefer your version.
>>
>> One question: I'm not sure if the following condition still holds 
>> with parallel execution of the caller.
>> ---------------------------------------------
>> if (caller_method->was_executed_more_than(1))  return false; // trust 
>> profile
>> ---------------------------------------------
>>
>> For example, assuming that the caller methods was executed 
>> concurrently by 12 threads, is it possible that 
>> caller_method->interpreter_invocation_count()=3 && profile.count()=0 
>> && no exception thrown earlier?
>> Thanks a lot.
>>
>> Best regards,
>> Jie
>>



More information about the hotspot-compiler-dev mailing list