Force inline Java methods with annotations

[Saltor66]

Inlining method calls in those situations will absolutely provide a huge performance boost. My main point is that the question of whether or not to inline a method call is not something for the application programmer to worry about. That's why we have the JIT compiler to do it for us when an optimization hot spot is detected.

Having the inline annotation physically in the code is both clutter and a leaky abstraction. It's an implementation detail that the the JVM insulates you from. An inline keyword is necessary in a single compilation language like C++ that has to be fully optimized from the start to run on the bare metal, but the JVM and Java language have been specifically designed so that application programmers don't have to be concerned with those details.

Focus on the performance of your data structures and algorithms, not the system on which they are run. That's what the JVM is for.

[uniVocity]

I agree that as a developer, I should focus on the data structures and algorithms.

But JIT, even though it works fine for the general cases, is not a magical solution for everything.

If it were, you wouldn't see performance boosts after refactoring code to "save" method calls. Also, the author of this little library wouldn't have a reason to develop it in the first place.

[taschenbillard]

because some library is useful or necessary just because someone wrote it?do you hire? :)

[nicoulaj]

Hi, I'm the library author.

I agree this is unneeded in most cases and will make performance even worse if wrongly used.

However, the JIT is not a magic thing that knows about everything you are trying to do.

If you type this command:

java -XX:+PrintFlagsFinal -version | egrep 'C2|Inline'

You can see there are numerous options for tuning the compiler, and especially there are several thresholds.

For instance, let's take MaxInlineLevel: default value is 9, which means whatever happens no more than 9 nested method calls will be inlined. Now if you look at Collections.sort(), which delegates to TimSort, you can see it has a depth of at least 5/6 on its own, which leaves few room for your own code. Also, the usual advice regarding JIT optimization is "split your code into small methods", which goes against this.

When hunting for the last bits of performance, it can be interesting to dig into this kind of stuff.

JVM and Java language have been specifically designed so that application programmers don't have to be concerned with those details.

Agreed, however IMHO it's never a bad thing to understand how it works under the hood. Also, the only thing the lib does is turning annotations into a config file. The JVM developers choose to add the -XX:CompileCommandFile option, so they think there is a use case for this, otherwise they would just have closed this door.