在Java 8与Java中编译的代码中编译的代码11

发布于 2025-02-06 05:44:59 字数 152 浏览 3 评论 0 原文

我们目前在Java 8中编译了代码，但我们正在Java 11 VM上运行该代码。现在，我们也试图将代码移至Java 11编译时间。想知道在Java 11性能中，Java 8与编译代码中编译的代码是否有任何好处，因为两个编译器都会产生不同的类文件（字节码）？一个与另一个在效率方面有何不同？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

逆夏时光 2025-02-13 05:44:59

javac 是不是优化编译器 t期望它会产生“更快的”字节码，从发行版到发行。优化是JVM的工作。

同时，Java Compiler dis 支持新的语言功能， May 支持新的JVM功能。其中一些确实具有性能影响。 JDK 9 -JDK 11中最著名的示例如下。

jep 280：indify string string confenation （jdk 9）。

此JEP改变了字符串串联表达式的方式。在JDK 9之前，字符串+表达式转换为
```
  new StringBuilder（）。append（）... append（）。toString（）;
 
```
尽管JIT认识到这种链条并试图在运行时进行优化，但这种优化是脆弱的，并不总是按预期工作。用 Invokedynamic 编译字符串串联使JVM更自由地生成更好的代码。您可以在
jep 181：基于巢的访问控制（JDK 11）

此JEP解决了访问嵌套类的私人成员的问题。在JDK 11之前，Java编译器为其生成合成桥方法（示例）。

）

乍一看，这与性能无关。但是，在边际案例另一种合成方法可能会因内部深度限制而破坏嵌入。

基于嵌套的访问控制允许Nestmate类互相访问彼此的私人成员而无需合成桥，从而降低了意外性能降解的风险。

更新

以前我包括“ noreferrer”> jdk-8175883：for loop for loop for for loop for for loop for for for loop for for loop for loop for in 在此列表中，但是正如@holger在评论中注意到的那样，这种“优化”实际上没有起作用。

结论

Java编译器的变化主要与新语言/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.

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: 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.
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.

回复收藏 0 原文

~没有更多了~