对解释语言的优势感到困惑

Question

我对编译语言这样的解释性语言(如java)的优势感到困惑.

解释语言(例如java)优于编译语言的标准解释是,相同的.class文件可以在不同类型的机器体系结构上运行.这怎么能节省你的工作？

对于每种不同的机器架构,您是否需要使用不同的编译器将相同的.class文件解释为机器语言？因此,如果您需要为每个不同的计算机体系结构使用不同的编译器来将相同的.class文件解释为机器代码,那么这如何为您节省任何工作？

为什么不直接使用.java源文件编译成机器语言的编译语言.当然这需要一个不同的编译器从java源文件编译为每个机器架构的机器语言,但是除了必须为每个机器编译从.class文件到机器语言的不同编译器之外,这又是什么呢？

我的意思是这与编译语言相同 - 无论是将java源文件编译为机器代码还是将类文件编译为机器代码,您都需要为每个机器架构编译一个编译器.

谢谢.

Answer 1

首先,声称"Java被解释",虽然它有一些事实依据,但是很有误导性,如果你只是从头脑中删除这个概念,那可能是最好的.

Java在构建时从源代码编译为中间表示(类文件,字节码).首次加载类时,大多数JVM实现(包括Oracle HotSpot和IBM J9)将经历一个短暂的解释阶段,但如果该类将以任何频率使用,则将运行动态编译器(JIT)并编译为本机代码.(有些JVM,比如JRockit,直接转到本机,没有解释器.)

我认为"为什么Java不直接编译为本机代码"是真正的问题.正如其他人所说,明显的答案是可移植性.但它比它更微妙:动态编译比静态编译产生更高质量的代码. 当代码被动态编译时,JIT知道没有静态编译器可以知道的东西:当前硬件的特征(CPU版本,步进级别,缓存行大小等),以及当前运行的属性(感谢分析数据)在解释期间聚集.)您的决策质量取决于您的信息质量; 与静态编译器相比,动态编译器可以获得更多更好的信息,因此可以产生更好的代码.

此外,动态编译器可以执行静态编译器无法实现的优化.例如,动态编译器可以进行推测性优化,如果它们变得无效或者它们的假设后来变得不正确,则将它们退出.(请参阅此处的"动态去优化":http://www.ibm.com/developerworks/library/j-jtp12214/).