交叉编译器与JVM
我想知道JVM的目的。 如果创建JVM以允许独立于平台的可执行代码，那么能够生成独立于平台的可执行代码的交叉编译器不能取代JVM吗？
有关交叉编译器的信息可从以下url获取： http ： //en.wikipedia.org/wiki/Cross_compiler
字节码格式和JVM的优点是能够在运行时根据实际运行期间获取的分析数据优化代码。 换句话说，没有静态编译的本机代码是一个胜利 。
运行时编译的一个特别有趣的例子是单态调用站点 ：对于调用实例方法的代码中的每个位置，运行时会准确跟踪调用该方法的对象类型。 在很多情况下，事实certificate只涉及一种对象类型，然后JVM将编译该调用，如果它是静态方法（不涉及vtable ）。 这将进一步允许它内联调用，然后进行更多优化，例如转义分析，寄存器分配，常量折叠等等。
事实上，你的批评可能（有人说应该 ）被颠倒过来：为什么Java根本定义字节码，修复许多可能留给实现的设计决策？ 现代趋势是分发源代码并让JIT编译器在其上工作。
JVM做的不仅仅是编译。 JVM是字节代码的解释器，它还包含编译字节代码的JIT（及时）编译器 – 但是根据应用程序的上下文，可以根据运行时上下文不同地编译相同的字节代码（它在运行时决定）如何编译字节码）。 JIT正在进行优化 – 它试图以最有效的方式编译代码。 交叉编译器不能（全部）这样做，因为它不知道你的代码将如何在运行时中使用。 这是JVM相对于交叉编译器的一大优势。
我以前没有使用过交叉编译器，但我想交叉编译器的优点是你可以更好地控制代码的编译方式。
平台独立可执行代码
这就是Java字节码。 “平台无关的可执行代码”的问题在于它不能是每个平台的原生（否则与平台无关将是一个微不足道，无趣的属性）。 换句话说，没有在所有平台上本机运行的格式。 根据您对术语的定义，JVM可以是定义Java字节码的ISA，也可以是允许Java字节码在可执行代码的本机格式不是Java字节码的平台上运行的组件。
当然，存在用于替代平台独立可执行代码的无限设计空间，并且上述对于所述空间的任何其他占用者都是如此。 所以是的，从某种意义上说，你可以用另一个为另一个独立于平台的可执行代码格式实现相同function的东西替换JVM。