Inlining in Java

Question

In C++ I can declare a method "inline" and the compiler is likely to inline it. As far as I understand there is no such keyword in Java.

Inlining is done if the JVM decides to do so? Can I influence this decision somehow?

Answer 1

Inlining is more likely to happen if the method in question is:

• short
• final
• not dependent on any long, non final methods

As these are the only circumstances where the JVM can be certain of the effects of the call.

Answer 2

Read this for Inlining behavior. http://www.javacoffeebreak.com/articles/thinkinginjava/comparingc++andjava.html

It says Final methods can be Inlined but not always.

Answer 3

class A {
    final int foo() { return 3; }
}

Given this class, any call to foo() can be replaced with the constant "3". Any Java1 virtual machine can do this, because the final keyword explicitly dictates that it isn't possible to have a subclass that overrides "int foo()".

Inlining the method provides the following benefits at the call site:

• No method call
• No dynamic dispatch
• Possible to constant-fold the value, eg. "a.foo()+2" becomes 5 with no code executed at
  runtime.

In the past, programmers often inserted the final keyword for exactly this reason. Or to better facilitate inlining and increase execution speed, they would combine many smaller methods into one larger method. But in many ways, such techniques defeat the entire facility of modularization and reusability built into the programming language.

Modern JVM, like the Java HotSpot VM is able to inline the class without the final. keyword**.

(http://java.sun.com/developer/technicalArticles/Networking/HotSpot/inlining.html)

Answer 4

A couple of the other answers have suggested that only final methods can be inlined - this is not true, as HotSpot is smart enough to be able to inline non-final methods so long as they haven't been overridden yet. When a class is loaded which overrides the method, it can undo its optimisation. Obviously making the method final mean that's never required...

Basically let the JVM do its job - it's likely to be a lot better at working out where to inline than you are.

Do you have a situation where you're convinced that the JVM isn't doing a good job? Assuming you're using HotSpot, have you tried using the server version instead of client? That can make a huge difference.

Answer 5

Yes, if the JVM decides to do it, it can. Ways to influence include setting the method as static or as final.

Of course, the most important thing about it is that the structure of the method needs to be inline friendly. Short helps, but most importantly it needs to only use its local variables and its parameters, no fields, and minimal method calls to other methods in the same class.

However you should not look to do such optimizations prematurely, you could actually be making things worse (because you could be short-circuiting other potential optimizations). The JVM will sometimes realize that a method can be inlined without these hints.

Answer 6

Although the java compiler can do inline (for short early-bound methods) the real inlining will be done by the JIT compiler. The JIT (HotSpot) compiler will be able to,even, inline virtual methods. The best way to interact with it is to write a simple and concise code. Most likely, code that uses Reflection will not allow for inlining.

Hope that helps.

Answer 7

'In C++ I can declare a method "inline" and the compiler will inline it'... or not. The compiler is free to make the function inline or not and you cannot really affect the result. It is only a hint to the compiler.

In Java there is no such thing, the compiler (and later the VM while performing optimizations) can decide to 'inline' the method.

Note that final methods have greater chances of being inlined (the compiler cannot inline non-final methods, as they may be overwritten in derived classes). With modern VM, a similar optimization can be made at runtime. The VM will flag the type (so it can perform type checks) and will inline the code. Only if the check fails, it will fall back into the original unoptimized polymorphic method call.