64位环境中的Java

欢迎进入Java社区论坛,与200万技术人员互动交流 >>进入

  内存管理器也有必须面对的问题。虽然具有较大的堆对性能有益,但为了使堆管理算法伸缩自如,这也加重了JVM的负担。虽然始终都有堆碎片的问题,但在堆较大时,这一问题就很严重了。编译器和优化器  为了实现快速启动,许多JVM选择在开始时首先解释Java字节码,在随后运行时再对这些字节码进行编译。然而,JRockit首先使用JIT(Just In Time)编译器编译代码。虽然启动时间稍长,但这样可以使应用程序能够从一开始就提高性能。为了实现快速启动,WebLogic JRockit不使用所有可能的编译器优化。虽然使用所有编译器优化可能会在应用程序执行的初始阶段获得较高性能,但在启动时间上的额外延长也被认为是不必要的。  从应用程序性能的角度考虑,使用所有优化去编译所有方法也是不必要的,因为编译时间也是应用程序执行时间的一部分。因此,不仅WebLogic JRockit不会在启动时完全优化所有方法,而且在整个应用程序运行期间,也会保留大量的方法不被优化。WebLogic JRockit仅选择改进后能够最大限度地提高应用程序性能的函数,然后仅对这一少部分方法进行优化。  WebLogic JRockit有两个各不相同但可以协同操作的代码生成器:JIT编译器和优化编译器。如图1所示。大多数方法只能遍历图表的左半边。某些选择方法将会利用优化编译器。

图1. BEA WebLogic JRockit有两条代码编译途径。

  WebLogic JRockit使用尖端的、低开销的、基于采样的技术来识别应该优化的函数。JVM包含一个采样器线程,该线程以周期性间隔唤醒,并检查几个应用程序线程的状态。它会识别每个线程正在执行什么方法,并记录某些执行历史纪录。采样器线程为所有方法跟踪此信息,当它发现频繁使用某一方法时,就会打上标记以便进行优化。在应用程序运行期间,较早的阶段会有大量这种优化机会,随着应用程序的继续执行,优化机会出现的速率不断下降。  由于方法的大小通常很小,而范围对代码调度程序非常重要,因此内嵌方法的优化是最重要的。调用方法的代码直接在调用点插入。在Java中,这可能很难完成,原因有很多,如在执行期间开始前,接口调用、远程调用和虚拟调用中被调用函数的标识未知。WebLogic JRockit拥有现成的技术,能够解决一部分问题。如果完成情况很差,则内嵌方法可能会导致代码膨胀,进而造成性能急剧下降。WebLogic JRockit包含精心调试过的启发式,可以防止这种性能下降。  WebLogic JRockit中的优化编译器包含许多基于Intel Itanium 2微体系结构的众所周知的代码生成技术。这些技术包括尖端的寄存器分配器,它可以充分利用Intel Itanium处理器系列的大寄存器堆栈(128个通用寄存器和128个浮点寄存器)。内存分配和垃圾收集  WebLogic JRockit的堆管理策略可以随线程数和堆空间大小一同缩放。内存分配通过线程本地数组完成;在堆上为每个线程分配约1000个对象的空间。这种方案可以提升数据的空间位置和临时位置,从而实现处理器缓存的高性能。还会大大降低线程间的同步,以便获得可分配给对象的堆空间。线程本地数组的大小是性能的重要参数,最佳大小取决于应用程序。WebLogic JRockit包含相应的启发式,可在应用程序执行期间对该参数进行调试。  WebLogic JRockit包含多种垃圾收集器,不同的应用程序可获益于不同的收集器。JVM包含相应的启发式,可以按各自适应方式为每个应用程序找到最佳的垃圾收集算法。所有的垃圾收集器在设计上都可以正确处理大型堆,算法可以利用堆中数据稀疏这一优势――即堆中包含的大多是由寿命短的对象形成的垃圾。  对垃圾收集器加以区分,根据是它们是否包含苗圃(代)、标记阶段是否多线程、扫除阶段是否多线程,以及收集器是与应用程序并发运行还是在进行垃圾收集期间停止应用程序。这些选择可以影响垃圾收集的频率和每次垃圾收集的持续时间(或暂停时间)。对于最大应用程序吞吐量,应该选择最小化总垃圾收集时间(垃圾收集频率的结果)和每次垃圾收集平均持续时间。但是在很多应用程序中,响应时间也是非常重要的,在这些情况下,必须确保暂停时间最小。WebLogic JRockit允许用户指出应用程序最重要的要求(响应时间或吞吐量),然后WebLogic JRockit将选择能够实现所选目标的垃圾收集方法。  碎片可能会成为严重的性能问题,尤其是在大型堆空间的情况下更是如此。在垃圾收集期间压缩堆空间将会解决这一问题,但会影响性能,因为压缩大型堆空间开销太大。避免压缩也有问题:堆的部分空间将无法使用,从而导致频繁进行垃圾收集。同样,位置也会影响处理器缓存的性能。  WebLogic JRockit使用滑动压缩窗口解决了这一问题。在每次垃圾收集期间,每次压缩堆的一个不同的小部分。在窗口大小适当的情况下,堆的性能与完全压缩一样好,而垃圾收集的开销却与不压缩一样小。  当SOA Java开发人员将他们的应用程序部署到使用JRockit的、基于Intel Itanium 2微处理器的平台上以后,既可以提高运算能力,同时又能获得所需的性能和可靠性。机不可失,马上使用这种技术吧!您最终会获益匪浅。  Itanium是Intel公司或其子公司在美国及其他国家的商标或注册商标。

[1][2]

快乐不是因为拥有的多而是计较的少

64位环境中的Java

相关文章:

你感兴趣的文章:

标签云: