为什么没有更多的Java软件本地编译？

我意识到字节码与本机代码（可移植性）的好处 。

但是，你总是知道你的代码将在x86架构上运行，为什么不编译为x86并获得性能优势呢？

请注意，我假设本机代码编译有性能提升。 有些人回答说实际上可能没有收获对我来说是个新闻。

Answer 1

因为性能提升（如果有的话）不值得麻烦。

此外， 垃圾收集对性能非常重要。 有可能的是，JVM的GC比嵌入在已编译的可执行文件中的更好，例如GCJ 。

并且及时编译甚至可以带来更好的性能，因为JIT有更多的信息可用于优化编译，而不是编译时的编译器。 请参阅JIT上的维基百科页面。

Answer 2

“Solaris”是一种操作系统，而不是CPU架构。 安装在实际机器上的JVM将编译为本机CPU指令。 Solaris可以是SPARC，x86或x86-64体系结构。

此外，JIT编译器可以根据您拥有的实际CPU系列进行特定于处理器的优化。 例如，Intel CPU上的不同指令序列比AMD CPU上的指令序列更快，并且针对您的确切平台的JIT编译器可以利用此信息来生成高度优化的代码。

Answer 3

字节码在为（示例）Solaris编译的Java虚拟机中运行。 它将像该操作系统一样进行优化。

在实际情况中，您通常会在运行时看到Java代码具有相同或更好的性能，因为它构建了虚拟机的内存管理代码 – 这些代码将在不断发展和成熟多年。

构建JVM的好处不仅仅是可移植性 – 例如，每次发布新的JVM时，编译的字节码都会获得业务中最好的优化，算法改进等。 另一方面，一旦你编译了C代码，那就是它。

Answer 4

因为使用Just-In-Time编译，所以可以获得微不足道的性能优势。

实际上，JIT实际上可以做得更快。

Answer 5

在运行之后，它已经由JIT编译成Solaris本机代码。 如果在上传目标站点之前编译它，则无法获得任何其他好处。

Answer 6

您可能会，也可能不会获得性能优势。 但更有可能会受到性能损失：静态编译不可能实现JIT优化，因此性能只会与编译器“蒙上眼睛”一样好（没有实际分析程序并相应地优化它，这就是像HotSpot这样的JIT编译器确实如此。

直观地说，如何廉价（资源方面）编译是非常令人惊讶的，并且只需观察正在运行的程序就可以自动优化多少。 黑魔法，但对我们有好处:-)

Answer 7

关于JIT的所有这些谈论都是大约七年过时的BTW。 现在所关注的技术称为HotSpot，它不仅仅是一个JIT。

Answer 8

“为什么不编译为x86”

因为那样你就无法利用它运行的特定cpu的特定function。 特别是，如果我们要将“compile for x86”读作“生成可以在386及其后代上运行的本机代码”，那么生成的代码就不能依赖于与mmx指令一样古老的代码。

因此，最终结果是您需要针对它将运行的每个确切体系结构进行编译（那些尚不存在的体系结构），并让安装程序选择要放置的可执行文件。 或者，我听说intel C ++编译器将生成相同function的多个版本，仅在使用的cpufunction上有所不同，并根据CPU报告的可用内容在运行时选择正确的。

另一方面，您可以将字节码视为“半编译”源，类似于本机编译器（除非要求）实际写入磁盘的中间格式。 然后，运行时环境可以进行最终编译，确切地知道将使用哪种体系结构。 这就是为什么一些C＃/ .net代码在某些基准测试中稍微优于某些cpu密集型任务上的c ++代码的原因。

字节码的“最终编译”还可以进行额外的优化假设（从静态编译角度来看）明显不安全*，如果以后发现这些假设错误，则重新编译。

Answer 9

我想因为JIT（及时）编译非常先进。