“有比Java字节码更好的方法来描述语义”？

Question

Cliff在他的演讲中点击“JVM就是这样吗？”，说“有比Java字节码有更好的方法来描述语义”：http://www.youtube.com/watch?v=uL2D3qzHtqY&t=8m55s

为什么呢？ Java字节码有什么问题？有哪些替代方案？

Answer 1

Bytecode已经失去了很多语义，这就是问题所在。它是一种非结构化的机器代码。作为一个例子，见证了Java反编译器的巨大复杂性：它基本上是C.S.I. Java团队，从分散在字节码周围的信息碎片中精心重建源代码。

由于现代JVM除了作为程序语义的描述之外没有太多用于字节码，因此它已经失去了它的原始目的，这是一种相对快速解释的格式，介于两者之间的描述级别中间。 Java和本机机器代码。

JIT编译器实际上有一个更难时间优化字节码，而不是原始源代码，因为它想尽可能多地了解一段代码背后的意图。考虑一下这段代码：

int i = 0;
String s = "";
for (Integer num : nums) { 
  s += num;
  if (++i < ints.size()) s += ", ";
}

代码是做什么的？经过一些分析并确认了一些猜想，结果发现它从整数列表中汇编了一个逗号分隔的字符串。但是，有很多事情需要优化：

1. 使用不可变String类型通过循环保存临时值;
2. 维护一个单独的索引变量i，该变量与隐式Iterator中保存的索引变量重复;
3. 每次都会根据列表大小检查i，即使很明显这只会在最后一次迭代时才会出现。

JIT编译器将定期执行循环特化优化：它将为最后一个循环步骤发出单独的代码，从而完全消除重复的if检查。它也可能意识到临时字符串没有转义并自动用基于StringBuilder的成语替换整个习语。

为了实现所有这一切，很明显编译器必须对正在发生的事情有一个非常全面的高级理解，使用源代码比生成的字节码更容易实现。

编程语言的现代趋势是将源代码本身作为JIT的入口点，或者与源代码非常相似的东西，如AST。

Answer 2

从快速扫描（不是完全倾听）谈话中，它似乎是关于Java隐藏用户细节的方式，以及它可能隐藏的其他细节的想法和/或操作系统可以更好地帮助的方式它

在这种情况下：他在谈论Java的抽象定义是字节码被解释的事实 - 解释字节码是一个非常缓慢的过程。但是“在幕后”，Java使用JIT编译器 - 在热点JIT中，使用性能分析来执行一些更复杂的优化 - 以“创建字节码快速运行的错觉”。

如果您正在开发下一代Java环境，操作系统或语言，这些区别很重要。

但就大多数人而言，这并不比现代处理器重叠执行某些指令的事实更有意义。除了知道它们是代码的可移植表示之外，大多数人都不会考虑字节码。他们编译Java。他们将它加载到他们的JVM中。它以合理的速度运行。完成。