Le 29/10/2024 à 11:55, Gary Gregory a écrit :
In addition, this change prevents the JVM from inlining
the code in some cases, see [1].
Interesting point, thank you for mentioning it. According to [1] method
inlining applies to static, final or private methods. The article has an
example with a static, non-final method.
I tested the inlining with the following code to see if there is a
difference between static and static final methods:
public class InliningTest {
public static void main(String[] args) {
long sum = 0;
for (int i = 0; i < 1000000; i++) {
sum += foo(i);
sum += bar(i);
}
System.out.println(sum);
}
public static long foo(int n) {
return n + 1;
}
public static final long bar(int n) {
return n + 1;
}
}
This was executed with Java 8 on Windows 10:
java -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions
-XX:+PrintInlining InliningTest
And here is the result:
187 32 % 4 InliningTest::main @ 4 (38 bytes)
@ 12 InliningTest::foo (5 bytes) inline (hot)
@ 19 InliningTest::bar (5 bytes) inline (hot)
Both methods were inlined at the same time. I got similar results with
Java 17 and 23. I tried with a private method and it was also inlined at
the same time.
So it looks like the final modifier doesn't affect the inlining of
static methods, what matters is if the method can be inlined (static,
final or private method with a size under the configured threshold) and
the number of calls to the method.
Emmanuel Bourg
[1] https://www.baeldung.com/jvm-method-inlining
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
