hotspot inlining decision seems to be random

Ulf Zibis Ulf.Zibis at
Mon Dec 14 08:13:37 PST 2009

Am 14.12.2009 13:36, Christian Thalinger schrieb:
> On Mon, 2009-12-14 at 12:22 +0100, Ulf Zibis wrote:
>> The Problem I have is, how to reliably see the effect of my code changes 
>> on the resulting performance.
>> For example, in [3] (at the end) you can see, that 
>> highSurrogate(char,char) is much faster than highSurrogate(int), if 
>> inlined. If not inlined [1],[2], it's opposite.
>> So how can I reliably force the inlining of method highSurrogate(...) as 
>> too as of decode(...) for my benchmark testing?
>> -XX:MaxInlineSize=250 seems not reliable
> OK, I think we should talk about what you really want to do.  I guess
> you want to write some code that is faster than what's currently in the
> JDK.  But I also guess you want that everyone else who is using your
> code has the same good (or better) performance than you have, right?
> Tuning around with inlining knobs is probably good for your particular
> micro-benchmark on your particular hardware.  But (almost) all other
> people run HotSpot with it's default inline settings...
> Your should think about if it's really worth tuning around so much at
> this level or if it wouldn't be better to spend more time on
> changing/factorizing your Java code that HotSpot can optimize your code
> for everybody. 
> -- Christian

Yes, you are completely right.

After changing/factorizing my Java code I was often confused about the 
results, I got from my benchmarks, because  they differed up to 50 % on 
consecutive runs.
Log time I thought, this is caused from differing parallel activity of 
other OS processes. So I came up interesting for the compiled code to 
see, what's happening behind the scenes.
Now I can see, that the inlining is random, even on more than 1,000,000 
loops on same code and even for tiny methods about 10 bytes length.

So how can I compare the benchmark results about my Java code against 
HotSpot with it's default inline settings without tuning around with 
inlining knobs and looking deeper into the disassembly results ?


More information about the hotspot-compiler-dev mailing list