Compiled code in java 8 vs Compiled code in java 11

user_1478852 0
Viewed 1436

We currently have code compiled in Java 8 but we are running that on Java 11 VM. Now we are trying to move our code to Java 11 compile time as well. Wondering if there are any benefits to compiled code in Java 8 vs Compiled code in Java 11 performance-wise, since both compilers will produce different class files (bytecode)? How does one differ from the other in terms of efficiency?

java-11 java-8 jvm compilation java
1 Answers

javac is not an optimizing compiler, so in general, don't expect it to produce "faster" bytecode from release to release. Optimization is a job of the JVM.

Meanwhile, Java Compiler does support new language features and may support new JVM features. Some of them indeed have performance implications. Most notable examples in JDK 9 - JDK 11 are the following.

  1. JEP 280: Indify String Concatenation (JDK 9).

    This JEP changes the way how string concatenation expressions are compiled. Before JDK 9, string + expression was translated to

    new StringBuilder().append()...append().toString();

    Although JIT recognizes such chains and tries to optimize them in runtime, this optimization is fragile and does not always work as expected. Compiling string concatenation with invokedynamic gives the JVM more freedom to produce better code. You may find the detailed explanation and benchmarks in the notes to this JEP.

  2. JEP 181: Nest-Based Access Control (JDK 11)

    This JEP solves the problem of accessing private members of nested classes. Before JDK 11, Java Compiler generated synthetic bridge methods for them (example).

    At first glance, this has nothing to do with performance. However, in marginal cases an additional synthetic method may break inlining due to inlining depth limit.

    Nest-Based Access Control allows nestmate classes to access private members of each other without synthetic bridges, thus reducing risk of accidential performance degradation.

Update

Previously I included JDK-8175883: Bytecode Generation for Enhanced for Loop in this list, but as @Holger noticed in the comments, this "optimization" didn't actually work.

Conclusion

Changes in Java Compiler are mostly related to new language/JVM features. Bytecode level optimization is not a goal. However, some of these changes may (indirectly) affect the performance, too. Anyway, the possible performance benefits from recompiling the code are usually so small that you won't even notice them in a real application.

user_34484190
Related