Method Inlining in the JVM

1. Introduction

In this tutorial, we’ll take a look at what method inlining is in the Java Virtual Machine and how it works.

We’ll also see how to get and read the information related to inlining from the JVM and what we can do with this information in order to optimize our code.

2. What Method Inlining Is?

Basically, inlining is a way to optimize compiled source code at runtime by replacing the invocations of the most often executed methods with its bodies.

Although there’s compilation involved, it’s not performed by the traditional javac compiler, but by the JVM itself. To be more precise, it’s the responsibility of the Just-In-Time (JIT) compiler, which is a part of the JVM; javac only produces a bytecode and lets JIT do the magic and optimize the source code.

One of the most important consequences of this approach is that if we compile the code using old Java, the same .class file will be faster on newer JVMs. This way we don’t need to recompile the source code, but only update Java.

3. How JIT Does It?

Essentially, the JIT compiler tries to inline the methods that we often call so that we can avoid the overhead of a method invocation. It takes two things into consideration when deciding whether to inline a method or not.

First, it uses counters to keep track of how many times we invoke the method. When the method is called more than a specific number of times, it becomes “hot”. This threshold is set to 10,000 by default, but we can configure it via the JVM flag during Java startup. We definitely don’t want to inline everything since it would be time-consuming and would produce a huge bytecode.

We should keep in mind that inlining will take place only when we get to a stable state. This means that we’ll need to repeat the execution several times to provide enough profiling information for the JIT compiler.

Furthermore, being “hot” does not guarantee that the method will be inlined. If it’s too big, the JIT won’t inline it. The acceptable size is limited by the -XX:FreqInlineSize= flag, which specifies the maximum number of bytecode instructions to inline for a method.

Nevertheless, it’s strongly recommended to not change the default value of this flag unless we’re absolutely certain of knowing what impact it could make. The default value depends on the platform – for 64-bit Linux, it’s 325.

The JIT inlines static, private, or final methods in general. And while public methods are also candidates for inlining, not every public method will necessarily be inlined. The JVM needs to determine that there’s only a single implementation of such a method. Any additional subclass would prevent inlining and the performance will inevitably decrease.

4. Finding Hot Methods

We surely don’t want to guess what the JIT is doing. Therefore, we need some way to see which methods are inlined or not inlined. We can easily achieve this and log all this information to the standard output by setting some additional JVM flags during startup:

-XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining

The first flag will log when JIT compilation happens. The second flag enables additional flags including -XX:+PrintInlining, which will print what methods are getting inlined and where.

This will show us the inlined methods in the form of a tree. The leaves are annotated and marked with one of the following options:

• inline (hot) – this method is marked as hot and is inlined
• too big – the method is not hot, but also its generated bytecode is too big, so it’s not inlined
• hot method too big – this is a hot method, but it’s not inlined since the bytecode is too big

We should pay attention to the third value and try to optimize methods with the label “hot method too big”.

Generally, if we find a hot method with a very complex conditional statement, we should try to separate the content of the if-statement and increase the granularity so that the JIT can optimize the code. The same goes for the switch and for-loop statements.

We can conclude that a manual method inlining is something that we don’t need to do in order to optimize our code. The JVM does it more efficiently, and we would possibly make the code long and hard to follow.

4.1. Example

Let’s now see how we can check this in practice. We’ll first create a simple class that calculates the sum of the first N consecutive positive integers:

public class ConsecutiveNumbersSum {

    private long totalSum;
    private int totalNumbers;

    public ConsecutiveNumbersSum(int totalNumbers) {
        this.totalNumbers = totalNumbers;
    }

    public long getTotalSum() {
        totalSum = 0;
        for (int i = 0; i < totalNumbers; i++) {
            totalSum += i;
        }
        return totalSum;
    }
}

Next, a simple method will make use of the class to perform the calculation:

private static long calculateSum(int n) {
    return new ConsecutiveNumbersSum(n).getTotalSum();
}

Finally, we’ll call the method a various number of times and see what happens:

for (int i = 1; i < NUMBERS_OF_ITERATIONS; i++) {
    calculateSum(i);
}

In the first run, we’re going to run it 1,000 times (less than the threshold value of 10,000 mentioned above). If we search the output for the calculateSum() method, we won’t find it. This is expected since we didn’t call it enough times.

If we now change the number of iterations to 15,000 and search the output again, we’ll see:

664 262 % com.baeldung.inlining.InliningExample::main @ 2 (21 bytes)
  @ 10   com.baeldung.inlining.InliningExample::calculateSum (12 bytes)   inline (hot)

We can see that this time the method fulfills the conditions for inlining and the JVM inlined it.

It’s noteworthy to mention again that if the method is too big, the JIT won’t inline it, regardless of the number of iterations. We can check this by adding another flag when running the application:

-XX:FreqInlineSize=10

As we can see in the previous output, the size of our method is 12 bytes. The -XX:FreqInlineSize flag will limit the method size eligible for inlining to 10 bytes. Consequentially, the inlining shouldn’t take place this time. And indeed, we can confirm this by taking another look at the output:

330 266 % com.baeldung.inlining.InliningExample::main @ 2 (21 bytes)
  @ 10   com.baeldung.inlining.InliningExample::calculateSum (12 bytes)   hot method too big

Although we’ve changed the flag value here for illustration purposes, we must emphasize the recommendation of not changing the default value of the -XX:FreqInlineSize flag unless absolutely necessary.

5. Conclusion

In this article, we saw what method inlining is in the JVM and how the JIT does it. We described how we can check if our methods are eligible for inlining or not and suggested how to make use of this information by trying to reduce the size of frequently called long methods that are too big to get inlined.

Finally, we illustrated how we can identify a hot method in practice.