How do I convince the JVM to inline an interface method?

Question

I have an class hierarchy rooted in an interface and implemented with an abstract base class. It something looks like this:

interface Shape {
  boolean checkFlag();
}

abstract class AbstractShape implements Shape {
  private boolean flag = false;

  protected AbstractShape() { /* compute flag value */ }

  public final boolean checkFlag() { return flag; }
}

interface HasSides extends Shape { 
  int numberOfSides();
}

interface HasFiniteArea extends Shape { 
  double area();
}

class Square extends AbstractShape implements HasSides, HasFiniteArea {

} 

class Circle extends AbstractShape implements HasFiniteArea { 
}

/** etc **/

When I sample the running code with VisualVM, it appears that AbstractShape.checkFlag() is never inlined and consumes 14% of total program running time, which is obscene for a method this simple, even for a method called so frequently.

I have marked the method final on the base class, and (currently) all classes implementing the "Shape" interface extend AbstractShape.

Am i interpreting the VisualVM sample results correctly? Is there any way to convince the JVM to inline this method or would I need to tear out the interfaces and just use an abstract base class? (I would prefer not to because the hierarchy includes interfaces like HasFiniteArea and HasSides which mean the hierachy does not have a perfect tree form)

EDIT: to be clear, this is a method that in any universe should be inlined. It is called more than 420 million times during a 2 minute execution and, because it is not inlined and remains a virtual call, it accounts for 14% of runtime. The question I'm asking is what is preventing the JVM from inlining this method and how do i fix it?

14% of what? 1ms? That is the fastest method you can probably write in Java. It just returns a value of the field. Why do you want it inlined? — Andrey Adamovich, Sep 27 '11 at 09:00
See also this: http://stackoverflow.com/questions/1159087/inlining-in-java — Andrey Adamovich, Sep 27 '11 at 09:03
This might be an issue of inlining not being done when profiling... — Thorbjørn Ravn Andersen, Sep 27 '11 at 09:44
@ThorbjørnRavnAndersen I think that's true for profiling, but I was sampling with VisualVM. Does this also interfere with inlining? — akbertram, Sep 27 '11 at 11:28
@AndreyAdamovich I know, right? This method **should not** be taking up 14% of runtime (in ms). My assumption is that it is only taking so much time because it is being dispatched virtually and that if it could be inlined I would reduce running time by ~14%. — akbertram, Sep 27 '11 at 11:33
if you run your program for 10s and your sampling shows that that method has taken 14% of those 10s, then it's not a true measurement, if you run your program for hours and then you get 14% of time, then you can say it's a problem with the method — Andrey Adamovich, Sep 27 '11 at 12:39
@AndreyAdamovich The runtime for this measurement was on the order of minutes, not seconds. — akbertram, May 10 '12 at 11:10

score 5 · Answer 1 · answered Sep 27 '11 at 09:37

5

Here is quote from the Wikipedia

A common misconception is that declaring a class or method final improves efficiency by allowing the compiler to directly insert the method inline wherever it is called. This is not completely true; the compiler is unable to do this because the classes are loaded at runtime and might not be the same version as the ones that were just compiled. Further, the runtime environment and JIT compiler have the information about exactly which classes have been loaded, and are able to make better decisions about when to inline, whether or not the method is final.

See also this article.

answered Sep 27 '11 at 09:37

Oleg Pavliv

20,462
7
59
75

+1: and as add on to this answer: final methods can obviously not be inlined, if they are implemented in several different classes!! Look at it from the standpoint of the JVM, all you have is a `Shape` how the heck should the JIT compiler know if there is later a Rect or an Oval behind that interface, and hwo should it know which method to call/inline? – Angel O'Sphere Sep 27 '11 at 11:07
@Angel O'Sphere Actually the JIT is capable of figuring that out. It's one of those pesky de-optimizations. "Since all classes so far extend AbstractShape we can call final method X directly without virtual call overhead" (same applies theoretically to inlining too). As soon as a class is loaded that implements Shape but not AbstractShape this has to be deoptimized again. The hotspot VM is doing that at least for interfaces that are implemented by only a single class (since that's a much-used idiom in Java that helps with performance) – Voo Sep 27 '11 at 23:01
Ah, I see your final sentence ;D yeah I did not mention that as most people wont grasp it. If you look at my wording I explicitely asumed two implementations would be present ;D – Angel O'Sphere Sep 28 '11 at 12:17
@AngelO'Sphere The JVM does lots of wonderful optimizations. As Voo said, it does have enough information to know that all (loaded) implementations of the interface inherit from the same base class and share the same final implementation of the method. The question is whether the JVM **actually** does this or if I need to refactor my code in order to benefit from inlining. – akbertram Sep 29 '11 at 15:38
The current HotSpot JVM actually does it. I thought that was meanwhile clearly answered by everyone here ;D However the JVM only optimzes and inlines this method if it concludes it is worth it, e.g. it is called often in a loop. However (looking at your last answer) there might be variations in JITing depending on platform (SPARC/x86 etc.) – Angel O'Sphere Oct 04 '11 at 11:15

score 1 · Answer 2 · answered Sep 27 '11 at 11:00

The default compiler threshold is 10000. -XX:CompilerThreshold= This means a method or a loop (for the server JVM) has to be called at least 10000 times before it is compiled to native code.

After it has been compiled it can be inlined, however the call stack does show this. It is smart enough to know the inlined code came from another method and you never see a truncated call stack.

profilers try sample code and assign time. It doesn't always do a great job and you get methods which are obvious not time consumers being assigned CPU time. VisualVM is a free profiler and it is implementing in Java. If you use a profiler like YourKit you can get more accurate results as it uses native code e.g. doesn't create garbage.

score 1 · Accepted Answer · answered Sep 29 '11 at 15:47

After extensive experimentation, I could not get the Sun JDK 6 to inline this method when called on the interface.

Fortunately, there were a limited number of call sites involved, and changing

public void paint(Shape shape) {
  if(shape.checkFlag()) { /* do stuff */ }
}

to

public void paint(Shape shape) {
  if(((AbstractShape)shape).checkFlag()) { /* .. */ }
}

is enough of a hint to get the JVM to inline the method. Running time of the calculation in question dropped 13% compared to the original runtime of 6 minutes.

That is the correct answer. It is not possible to inline methods on interfaces. You can enable `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and in the output you will see something like `Line 12345: @90 com.example.app::paint (3 bytes) not inlineable`. — kap, Oct 27 '22 at 07:51

score 0 · Answer 4 · answered Sep 27 '11 at 09:09

From the literature I've read on old versions of JVM's by declaring methods final it would determine it to transform that method inline. Now you don't have to specify that method to be final to optimize the code.

You should let the JVM optimize the code, and make the method final only if you explicitly don't want that method overridden. The JVM probably doesn't make your method inline because its own optimization is faster, considering the rest of the application's code.

How do I convince the JVM to inline an interface method?

4 Answers4