Inline threshold relative to frequency

[Ulf Zibis]

Here the Bug Id's:

6908238 - HotSpot compiler should handle inlining threshold dynamically 
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6908238>
6908240 - javac should avoid copy & paste same code 
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6908240>

Please review,

-Ulf


Am 04.12.2009 20:44, Ulf Zibis schrieb:
> I have filed 2 bugs:
>    internal review ID: 1665161
>    internal review ID: 1665163
>
> Please review,
>
> -Ulf
>
>
> Am 23.11.2009 11:38, Christian Thalinger schrieb:
>> On Sun, 2009-11-22 at 00:49 +0100, Ulf Zibis wrote:
>>  
>>> Hi,
>>>
>>> wouldn't it make sense, if the inline threshold for a method would 
>>> be relative to the frequency of it's usage?
>>>
>>> See the method below. It has 189 bytes of byte code, so it "too big" 
>>> under default inline threshold.
>>> As it is called very frequent, performance should increase 
>>> "dramatically", if it could be inlined, as the pushing of the 
>>> numerous parameters to stack could be saved.
>>>     
>>
>> Well, it "could" be a good idea but it does not necessarily increase
>> "dramatically" performance.  It's not easy to find good inlining
>> heuristics that work in all cases.
>>
>> Inlining a rather big method, like yours, has a number side-effects to
>> the caller, most importantly:
>>
>> a) it becomes bigger -> cache effects
>> b) register pressure might increase -> worse register allocation (but
>> could be the other way around)
>>
>> Also note that not all architectures use the stack for passing call
>> arguments.  Even x86_64 has enough argument registers for this
>> particular method.
>>
>> -- Christian
>>
>>
>>   
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20091222/3c323bea/attachment.html