英语原文共 5 页，剩余内容已隐藏，支付完成后下载完整资料

针对Web服务的JVM上各种垃圾收集器的性能比较

摘要

当前的电子商务对Java服务器端应用程序效率的要求越来越高。因此，需要保证Java虚拟机的连续可用性和较快的响应时间以满足远程客户端的连续请求。本项目研究了如何优化JVM（尤其是三层架构的Java服务器端应用程序）中的垃圾收集器，以提高系统实时处理的吞吐量，充分利用CPU的处理时间，提高内存的使用率以加大系统的负载。本项目研究了五个JikesRVM垃圾收集器的特性和体系结构，它们分别是CopyMS，GenMS，SemiSpace，GenCopy和MarkSweep。本项目确定了性能最好的垃圾收集器，并发现了造成这些开销的主要原因。本项目使用基准测试套件SPECjbb2000模拟三层架构的Java服务器端应用程序。我们使用SPECjbb2000对五个不同的垃圾收集器分别就大、小内存进行了测试比较。结果，我们发现对于大堆，CopyMS具有最佳的平均吞吐量，而GenMS在内存有限时具有最佳的整体性能，并且可以处理较大的工作负载。另一方面，GenCopy和SemiSpace在处理轻型工作负载方面有着更高的效率。垃圾收集器的性能与所使用的堆的大小成正比。内存碎片和较长的暂停时间是在提高应用程序性能时所要面临的两个主要挑战。我们在报告的结尾提出了对未来优化垃圾收集器的建议。

I.引言

如今，电子商务对Java服务器端应用程序的需求日益增加，因此应用程序的负载越来越重。 Java虚拟机（JVM）是​​Java服务器端应用程序的核心，所有的Java程序都运行在这个抽象的计算机之上。它可以协调应用程序，处理命令，进行逻辑决策和评估，并根据用户请求进行相关计算。此外，它是一个虚拟处理器，可以针对不同的平台创建不同的二进制文件，使得Java程序在不同的平台有相同的运行效果，并且它与硬件处理器具有相同的处理逻辑。因此，它与一个真正的处理器相差无几。为了处理大量用户请求，需要保证Java虚拟机的连续可用性和较快的响应时间以满足连续请求。

本文所介绍的研究项目，其目的是针对Java服务器端应用程序的JVM中的垃圾收集器（GC）提出优化方案。 JVM经过优化，响应时间缩短，CPU时间得到充分利用，内存使用率得到有效提高，从而可以执行更多的实时处理，处理更大的工作负载。本项目的目标是使吞吐量提高10％。优化的目标是减少GC的时间开销，提高内存使用率，缩短暂停时间，增加可伸缩性，提高缓存局部性，实现主机系统的更好集成。重点是针对Java服务器端应用程序优化JVM中的GC。基准测试套件SPECjbb2000用于模拟Java服务器端应用程序。本项目选择JikesRVM作为研究平台。GC是一种从未使用的对象中回收内存的机制。JIkesRVM中存在五种GC,分别是Mark-Sweep、Semi-Space、Generation-Mark-Sweep、Copy-Mark-Sweep和Generational-Copy。我们对这些GC的特性和体系结构进行了研究，确定了影响GC性能和开销的主要原因，我们对于这五种GC在Java服务器端应用程序上的表现进行了测试比较，确定了拥有最佳性能的GC。此外，还提出了了提高JVM性能的方法，使得JVM可以处理更多的工作负载，从而提高了Java服务器端应用程序吞吐量。

II.实验细节

在本实验中，我们之所以选择JikesRVM，是因为它是开放的测试平台，可以为新的虚拟机技术提供原型，并且它具有高配置的内存管理工具包可用于研究。对于操作系统，我们之所以选择Fedora Core 4，是因为它支持多用户环境，开源并且对于Java服务器端应用程序有很好的支持。硬件平台是Intel P4 2.0GHz。为了模拟Java服务器端应用程序，我们使用了基准测试套件SPECjbb2000。 SPECjbb2000是SPEC第一个用来评估服务器端Java性能的基准。它是一个Java程序，用于模拟三层架构的系统，并且对于系统中间层有较好的支持。

我们的系统模拟的是一家批发公司，其仓库服务于多个地区。它模拟客户操作，例如建立新的订单或查询现有订单的状态。公司内部还会产生其他操作，例如处理交货订单，处理客户付款以及检查库存状态。它用Java类代替数据库表，用Java对象替代替数据记录。这些对象使用二叉树（也包括Java对象）或其他数据对象保存，因此它没有任何I/O磁盘或I/O网络操作。在此基准测试套件中，每个仓库仅有一个客户端处于活动状态。终端直接映射到Java线程。每个线程依次执行操作，每个操作按照概率分布进行选择。线程数与仓库数成正比。业务逻辑是JlikesRVM处理SPECjbb2000所生成的线程。

SPECjbb2000测量JikesRVM的吞吐量，即每秒执行的业务操作的速率。它还可以测量仓库使用的堆大小。实验中有五个要测试的GC，例如MarkSweep，Semi-Space，GenCopy，GenMS和CopyMS。实验结果将在下一节中介绍。我们通过使用不同的参数设置来确定哪个GC具有良好的性能，并根据SPECjbb2000中测量的的平均吞吐量和堆大小确定最佳的GC，从而完成实验。为了检测五个不同的GC，SPECjbb2000将配置多达25个仓库，并全部添加到JikesRVM中。此实验是为了测试具有特定GC的JikesRVM可以处理的最大工作负载。总堆大小固定为400MB。对于第二个实验，堆大小固定为200M。

III.结果

A.SPECJBB2000性能指标

所添加的仓库由配置文件中的开始，增量和结束参数确定。这些参数指定要同时运行的一系列仓库数量。例如，分别设置start = l，increment = l和end = 10，程序将首先运行仓库，然后2个仓库并发运行，然后3个仓库，依此类推，直到10个仓库并发运行。

SPECjbb2000的性能指标是平均吞吐量，至少是预期产生峰值吞吐量的仓库数量的两倍。例如，如果该点的高峰在4个仓库中，则将度量标准点从4个仓库中取出，并增加该点的所有吞吐量，然后除以5，得出度量结果。每个仓库的吞吐量是通过将每个仓库中操作的总计数相加并除以执行操作所花费的总时间来计算的。每个仓库都有五种操作类型，例如新订单，付款，订单状态，交货和库存水平。

B.堆大小为400MB时五种GC的性能

图I（a）显示了JikesRVM中五个不同GC的性能，分别是CopyMS，GenCopy，MarkSweep，SemiSpace和GenMS。图1（b）显示了五个不同GC所使用的堆。表I（a）和4.1（b）分别显示了处于最大吞吐量和最大仓库运行数量时堆的使用率。 GenMS最多可处理21个仓库，其仓库数量最多。它可以充分利用堆，使用率达到了99.45％，但是对于的堆的使用率的波动非常大，与吞吐量相似。其次，CopyMS和MarkSweep都可以处理多达18个仓库，但是MarkSweep所使用的堆平均比CopyMS高，而且CopyMS的平均吞吐量也比MarkSweep高。最后，GenCopy和SemiSpace最多只能处理10个仓库，但用于SemiSpace的平均堆空间最低。

对于从1到3个仓库的轻载，GenCopy可以实现最佳性能，并且最大吞吐量为6975.69 ops/s，与其他GC相比，这是在3个仓库运行时的最高吞吐量，并且使用了29.1％堆，但此后数据显着下降。SemiSpace在运行4个仓库时表现良好，吞吐量最高点达到6933.64 ops/s，最低堆使用率为20.53％。另一方面，CopyMS在运行5个仓库时具有最高的吞吐量，从7个仓库到15个仓库，它可以实现最大吞吐量，在运行5个仓库中具有6688.47 ops/s的吞吐量。运行完10个仓库后，SemiSpace和GenCopy的内存不足，但是使用的最大堆分别仅为47.18％和48.5％。在执行17个仓库期间，MarkSweep可以实现最佳性能，但是在18个仓库之后，MarkSweep会耗尽内存，并使用93％的堆。最后，只有GenMS可以继续运行直到21个仓库。对于GenMS，其吞吐量的波动非常明显，而CopyMS和MarkSweep更一致。当运行的仓库数量增加时，CopyMS，SemiSpace和MarkSweep的吞吐量会降低，而当接近最大仓库数量以及它们使用的最大堆时，丢弃率会更高。但是，对于GenMS，其吞吐量从17个仓库突然增加到20个。最高的平均堆使用率是GenMS，尽管它波动并且呈锯齿状。根据表I（a），CopyMS，GenCopy和GenCopy可以使用20％到30％的堆来实现最大吞吐量，而GenMS和MarkSweep可以使用50％的堆来实现最大吞吐量。

从这两个图中可以得出结论，CopyMS为SPECjbb2000实现了最佳的平均性能，并且其平均堆使用率是其他GC堆使用率的平均值，而GenMS可以处理的仓库数量最多，其平均堆使用率最高，而GenCopy对于轻型工作负载表现良好。另一方面，SemiSpace具有最低的堆使用率平均值。最后，MarkSweep的性能大约是平均水平，但平均使用的堆却很高。

B.堆大小为200MB时五种GC的性能

图2（a）显示了堆大小为200MB时五个不同GC的性能。图2（b）显示了它们使用的堆的情况。表2（a）显示了GC达到最大吞吐量时所使用的堆的使用率和运行的仓库的数量，表2（b）显示了仓库运行数量达到最大时GC所使用的堆的使用率及其吞吐量。当运行一个仓库时，GenMS所使用的堆最大，为99MB。显然，GenMS可以处理最多数量的仓库，即9个仓库，并且可以充分利用高达95.7％的堆，其次是MarkSweep和CopyMS，可以处理8个仓库。 GenCopy只能处理4个仓库，而SemiSpace可以处理5个仓库。当运行1个仓库时，SemiSpace在堆的使用率最低的情况下表现良好，但是当运行2个仓库和3个仓库时，GenCopy的性能最佳，当运行两个仓库时，它的最大吞吐量为6724.9 ops/s，高于运行其他数量仓库时的吞吐量。从运行5个仓库开始，直到运行9个仓库，GenMS的性能都优于其余GC，其最大吞吐量可达到6493.64 ops/s，可以运行3个仓库，堆的使用率为66.9%。但是，CopyMS还在运行3个仓库中实现了最大吞吐量，其吞吐量为6455.46 ops/s，堆的使用率为39.55％。SemiSpace对于堆的使用率是其他GC中最低的。当仓库继续增加并且使用的堆接近最大值时，所有GC的吞吐量都在下降。 MarkSweep的平均性能低于CopyMS，但堆的使用率高于CopyMS。对于运行1到2个仓库，GenCopy和GenMS堆的使用率相似，但是之后，GenCopy堆的使用率会下降，GenMS会增加。另一方面，用于MarkSweep的堆的大小与运行的仓库数量成正比。 在运行相同数量的仓库时，当吞吐量达到最大时，GenCopy和SemiSpace堆的使用率分别为42.3%和26.6%。

从这两个图可以得出结论，GenMS可以达到最佳的平均吞吐量并充分利用堆。此外，它还可以处理多大9个仓库的工作负载。其次，SemiSpace和GenCopy在轻型工作负载下表现良好。最后，SemiSpace对于堆的使用率较低。

图3显示了堆大小分别为200MB和400MB时五个不同GC所达到的吞吐量和堆的使用率的比较情况。首先，很明显，堆大小为200MB时GC的最大吞吐量小于堆大小为400MB时GC的最大吞吐量。此外，在仓库运行数量为GC在堆大小为200MB时处理的最大仓库数量的前提下，除GenMS外，其余GC在堆大小为200MB时的平均吞吐量均小于在堆大小为400MB时的平均吞吐量。在堆大小为400MB时，GenMS的波动更大，随着仓库的增加（最多增加到9个仓库），GenMS在堆大小为200MB时的平均吞吐量高于堆大小为400MB时的平均吞吐量。除GenCopy之外，在堆大小为200MB和堆大小为400MB时，GC所使用的平均堆大致相当。由图可知，在堆大小为200MB时堆的使用率与运行的仓库数量成反比，而堆大小为400MB时则成反比。

从表III（a）中可以看出，堆大小为400MB时所有GC的最大吞吐量都高于堆大小为200MB时的最大吞吐量。与堆大小为200MB时相比，在堆大小为400MB时，所有的GC都在达到最大的吞吐量时，堆的使用率都较低。从表III（b）中可以看到，与堆大小为200MB时相比，堆大小为400MB时，CopyMS，GenCopy和GenMS的堆的使用率更高，但SemiSpace和MarkSweep则相反。此外，在堆大小为200MB时，与堆大小为400MB时相比，当GC（除Mark Sweep）处理的仓库数以及堆的使用量达到最大时， 其所能达到的吞吐量都会更高。

最后，从表3、表III（a）和表III（b）可以得出结论，除GenBank外，和堆大小为200MB相比，堆大小为400MB时GC的平均性能更好。此外，和堆大小为200MB相比，堆大小为400MB时GC能够在堆的使用率更低的情况下达到最大吞吐量。最后，在堆大小为200MB时，与堆大小为400MB时相比，当GC（除Mark Sweep）处理的仓库数以及堆的使用量达到最大时， 其所能达到的吞吐量都会更高。

IV.讨论

目前我们探讨了JikesRVM中五个垃圾收集器CopyMS、GenCopy、MarkSweep、SemiSpace和GenMS的特性和体系结构，并研究了它们在Java服务器端应用程序中的性能。我们使用了基准测试套件SPECjbb2000用于评估Java服务器端应用程序的性能。此外，本文为在JikesRVM中优化垃圾收集器做出了积极的贡献。通过分析SPECjbb2000的结果，当使用的堆大小为400MB时，CopyMS在SPEC

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[235245]，资料为PDF文档或Word文档，PDF文档可免费转换为Word