Inline threshold relative to frequency

[Ulf Zibis]

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
>   

In my code example the regarding method is only called from 2 places, so 
the additional memory would not count so much here, and on the other 
hand the by-stack passing of 6 parameter arguments could be saved, so 
the amount of method parameters should be too valued for such a 
dynamic-threshold.

In reference to my other thread "Multiple copies of same code" removing 
the 6 copies of the finally block would save more memory/cache.

> 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.
>   

Does that mean, that all the
          MOV    EBP,[ESP + #72]
          MOV    [ESP + #4],EBP
pairs would be optimized to register usage in a following optimization 
step, I can't see by PrintAssembly?


-Ulf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20091124/4e5a9975/attachment.html