Java 8中的已编译代码与Java 11中的已编译代码 [英] Compiled code in java 8 vs Compiled code in java 11
问题描述
我们目前已使用Java 8编译了代码，但我们正在Java 11 VM上运行该代码. 现在，我们也尝试将代码移至Java 11编译时.想知道Java 8中的编译代码与Java 11中的编译代码在性能方面是否有好处，因为两个编译器都会产生不同的类文件(字节码)?在效率方面，一个与另一个有何不同?
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?
推荐答案
javac是不是优化编译器，因此通常不要期望它会产生更快"的结果.发行版之间的字节码.优化是JVM的工作.
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.
与此同时，Java编译器 支持新的语言功能，而可能支持新的JVM功能.其中一些确实对性能有影响.以下是JDK 9-JDK 11中最著名的示例.
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.
-
JEP 280:简化字符串连接(JDK 9).
此JEP更改了字符串连接表达式的编译方式.在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();
尽管JIT会识别此类链并尝试在运行时对其进行优化，但这种优化是脆弱的，并不总是能按预期工作.使用invokedynamic编译字符串连接使JVM具有更多自由来生成更好的代码.您可以在此JEP的说明中找到详细的说明和基准.
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.
JEP 181:基于嵌套的访问控制(JDK 11)
此JEP解决了访问嵌套类的私有成员的问题.在JDK 11之前，Java编译器为它们生成了合成桥接方法(示例).
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.
基于嵌套的访问控制使Nestmate类无需合成桥即可访问彼此的私有成员，从而降低了意外性能降低的风险.
Nest-Based Access Control allows nestmate classes to access private members of each other without synthetic bridges, thus reducing risk of accidential performance degradation.
更新
以前，我在其中包含 JDK-8175883:用于增强循环的字节码生成此列表，但正如@Holger在评论中注意到的那样，此优化"是指并没有真正起作用.
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.
结论
Java编译器中的更改主要与新的语言/JVM功能有关.字节码级别的优化不是目标.但是，其中一些更改也可能(间接)影响性能.无论如何，重新编译代码可能带来的性能好处通常很小，以至于您甚至在实际的应用程序中都不会注意到它们.
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.
这篇关于Java 8中的已编译代码与Java 11中的已编译代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
