实现所有的 Java 语言功能所要求的核心功能就是全部工作，但有待于完成。一些更深奥的线程功能 ― 暂挂、恢复、时间等待等等 ― 还有待于实现。负载平衡算法还处在在初步阶段。还未提供对最终化、弱引用和类验证的支持。快速编译器接近完成。优化编译器的基础框架和它的一些级别 1 的优化已经完成并运行。更高级的优化正在开发之中。联机测量和控制器子系统处在设计阶段。
Jalape�o 对 Java 库代码的支持受到 Jalape�o 写成 Java 代码的限制。Jalape�o 能够处理写成 Java 代码的库方法，但本机方法必须重写。实现 Java 本机接口（Java Native Interface（JNI））将允许 Jalape�o 调用写给这种接口的本机方法，但不能调用某些本机方法。JNI 是一个特别难解决的问题，因为它是虚拟机的 C 语言接口，而在 Jalape�o 中，虚拟机不是用 C 编写的。我们还不知道当我们试图在 Jalape�o 中提供 JNI 服务时会出现什么性能或实现问题。
Jalape�o 项目正处在过渡阶段。初始功能大多已经实现。Jalape�o 的很多机制仍处于初步阶段。现在是测量性能、识别瓶颈并用更高效的实现取代它的时候了。一些“低挂的果实”已被采摘：例如，无争用的锁获取已经被改成内联。然而，基线编译代码的性能量度是如此没有说服力以致于我们只好勉强信任我们的量度，直到优化编译器可用。
在功能和性能上也还有错误有待于隔离、识别和修复。
要想评估 Jalape�o 的当前性能，将它与 AIX 下的 IBM Developer Kit（DK）中的 JVM 作个比较是有帮助的，该 JVM 是东京 IBM 开发的使用 JIT 编译器的 Java 技术版，版本 1.1.8。 31 应该注意到，Jalape�o 的目标奢侈地针对 SMP 服务器，而 IBM JVM 必须适应于所有运行 AIX 的 PowerPC 计算机。读者的脑海中也应记住这里提出的性能图代表的是某个时间点上的快照：Jalape�o 和 IBM JVM 都不时得到改善。
性能图针对 Jalape�o 的基线和优化编译器。对两种情况，引导映象都用优化编译器编译过，而指定编译器主要用于指定的应用程序（和 JVM 的任何动态链接类）。优化编译器图反映当前实现了的级别 1 优化。非繁衍拷贝内存管理器在两种情况中都使用。
图 7 比较了 Jalape�o 的基线和优化编译器（用 Java 语言编写并由 Jalape�o 的优化编译器优化）以及 IBM DK JIT 编译器（用本机代码实现）花费的编译时间。基线编译器是明显的胜出者，其运行比 JIT 编译器快 30 到 45 倍。优化编译器差不多与 JIT 编译器一样快，但没它快。
图 8 把三个编译器生成的代码的性能和 Symantec 的微基准程序（microbenchmark）上的不使用 JIT 编译器的 IBM DK 的解释代码的性能作了一个比较。 32 （该图已被删改以简化 Jalape�o 的优化编译器和 IBM DK JIT 编译器间的性能比较。）基线编译后的代码始终是解释后的代码的两倍快。IBM JIT 编译后的代码快得多：比解释后的代码快 4 到 40 倍。Jalape�o 的优化编译器与 JIT 编译器大致相当。
图 9 在运行在中等大小的（10%）问题上的 SPECjvm98 基准程序 33 上做了相同的比较。 34 基线编译器再一次通常是解释器的两倍好。JIT 编译器再一次快得多。优化编译器再一次通常与 JIT 相当。
图 10 显示了在使用可移植业务对象基准程序（portable business object benchmark，pBOB 版本 2.0a）的 12 路 SMP（带运行 AIX 4.3 的 262 MHz PowerPC S7a 处理器）上的 12 个虚拟处理器上运行的 Jalape�o 优化编译器的性能。这个模型按照 TPC-C 规范建立的基准程序（请参阅 Baylor 等人 35 对这个问题的讨论以了解细节），模拟了事务工作负载中的业务逻辑。一直到 10 个仓库（warehouse），性能几乎是线性地提高，在 13 个仓库时达到峰值，然后缓慢地降低。这表明，到少在这个基准程序上，Jalape�o 伸缩得很好。
扫一扫
1064
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
