JVM是32 OR 64 BIT？

Question

在here上阅读本书时。

我可以看到以下部分，其中说：

  

32 OR 64 BIT？如果您有32位操作系统，则必须使用   一个32位版本的JVM。如果您有64位操作系统，   然后您可以选择使用32位或64位版本的Java。   不要以为只是因为你有一个64位操作系统，你   还必须使用64位版本的Java。

     

如果堆的大小小于约3 GB，则为32位   Java版本将更快，占用空间更小。这是   因为JVM中的内存引用只有32位，而且   操纵那些内存引用要比它便宜   操作64位引用（即使您有64位CPU）。该   32位引用也使用较少的内存。

     

第8章讨论了压缩oops，这是JVM可以使用的方式   即使在64位JVM中也使用32位地址。然而，即使有   这种优化，64位JVM将占用更大的空间，因为   它使用的本机代码仍然具有64位地址。

     

32位JVM的缺点是总进程大小必须是   小于4GB（在某些版本的Windows上为3GB，在某些旧版本上为3.5GB）   Linux版本）。这包括堆，permgen和本机   JVM使用的代码和本机内存。广泛使用的程序   在32位JVM上，长或双变量的速度会慢一些，因为   他们不能使用CPU的64位寄存器，尽管这是非常的   例外情况。

     

适合32位地址空间的程序可以在任何地方运行   32位JVM比同类配置快5％到20％之间   64位JVM。前面讨论过的库存批处理程序   例如，在我的32位JVM上运行时，章节速度提高了20％   桌面。

这些行说明，对于较小的堆大小（小于3GB），32位会更快。如果这是真的，我想知道它背后的原因，是什么让32位JVM更快？

Answer 1

我对作者声称使用32位版本的JVM可以提高5％到20％的性能持怀疑态度。但是，我没有太多使用Java，所以我不确定。但为了调查这一说法，我查看了SPEC的一些结果。

我搜索了SPECjEnterprise2010的结果，x86-64架构的最高分为an Oracle system that used a 64-bit version of the JVM。

我还查看了SPECjvm2008，以防这些较小的工作负载可能受益于32位架构。但是best performing x86-64 system, this time from Huawei,再次使用64位版本的JVM。

如果32位版本的JVM确实更好，我希望人们提交他们的SPEC结果会在调整他们的工作负载时选择（但我可能是错的）。

我不怀疑有一些工作负载，其中32位版本的JVM将胜过64位版本。正如其他人已经注意到它为地址使用更多内存。但是，x86-64架构有更多可用的寄存器，我怀疑64位操作模式是大多数优化工作的重点。

系统性能有很多组件，我不认为32位版本的JVM必然会胜过64位版本（对于这一点，这只会对CPU绑定工作负载产生影响）。我要说的是，如果你在性能调优过程中达到这一点，你会想要检查两个不同选项的自己的工作量，并使用你自己的测试结果做出决定而不是假设使用32位优于64位因为根据经验节省了地址的存储空间，因为还有其他因素可能比这更重要。

Answer 2

这更多是一般表现的问题。如果你有一个最近的64位处理器和大量未使用的内存，使用JVM 32而不是JVM 64的唯一可能的增益是一些循环可以完全适合具有32位地址的高速缓存而不是64位那些导致较少的主存储器使用32位JVM访问。我真的无法评估增益，但除非在非常特殊的情况下我怀疑它达到5％到20％ - 请注意我只是怀疑，不确定......

但是如果您使用资源有限的系统，最终因为您想要优化硬件并在其上运行许多虚拟机，32位JVM将使用比64位JVM少得多的内存。它将为其他应用程序和系统留出更多可用内存，从而避免交换并允许系统更好地缓存磁盘IO。

恕我直言，没有一般规则。我只会使用以下经验法则：如果JVM 和所有其他应用程序正在运行，系统仍有足够的内存用于缓存IO，我会使用64位JVM和32位一个相反的情况。

当然，只有Java应用程序本身不需要大量使用64位JVM的内存 - 并且最终在必要时向系统添加更多内存时才有意义，因为现在内存不是那么昂贵< / p>

Answer 3

没有简单的答案，最好的办法就是针对您的具体应用进行尝试。但你应该记住，还有很多其他选择，例如关于JIT，垃圾收集算法，RAM限制，可能比建筑选择的影响更大，因此您必须将这些包含在测量中。

如果您曾经问​​过这个问题，换句话说就是选择，这意味着您已经在具有32位模式的64位系统上运行（具有可接受的性能，即没有软件仿真） ）最有可能是AMD64又名x86-64。

在这样的系统上，Oracle的JVM支持“压缩oops”，这意味着只要最大堆不超过32 GB，就可以在Java堆中使用32位引用（如果确实如此，我怀疑使用32位是一个有效的选择那个应用程序）。与32位JVM相比，它可能仍然消耗更多RAM，因为某些组件仍然需要使用64位指针，但这些通常不是应用程序的性能相关部分。

请注意，对于使用64位模式的AMD64 aka x86-64架构，不仅仅意味着更改指针大小。注意只允许它使用每个寄存器64位，它还有更多可用寄存器。它实际上是在同一芯片中实现的不同架构，并且取决于您的应用，使其可能是一个很大的改进。

但正如所说，用真实应用程序测试它是获得正确答案的唯一有效方法。

Answer 4

如果您打算使用其中一个Oracle VM，那么问题就变成了您是否要使用客户端或服务器JIT，因为Oracle还没有可用于任何64位CPU的客户端JIT。

服务器虚拟机可用于32位和64位CPU，x86 / AMD64 CPU上服务器虚拟机的性能差异相当小（根据我的经验，它在Windows上不到+/- 5％或者Linux），虽然64位VM通常需要大约20％的内存。

如果您的应用程序需要大于1.3GB的堆内存大小，则必须使用64位服务器VM，因为来自Oracle的32位虚拟机不会以堆大于此值的方式启动（在Linux上限制略高）。

客户端JIT的主要优点是它具有更快的启动时间。使用此VM，您可以在不到100毫秒的时间内完成相当多的认真工作，而即使打开分层编译，服务器VM也只需要一秒钟即可开始。客户端VM还需要比服务器VM少得多的内存，并且可以在同一台计算机上的多个VM实例之间形成class data sharing。

另一方面，服务器VM往往能够以相当快的速度执行计算密集型代码。实际性能差异根据您执行的代码而有很大差异，但可能介于约-10％和+ 200％之间。对于运行时间超过几百毫秒的任何事情，它通常至少快30％。

您可以使用各种选项调整两个JIT，使它们的行为更相似，但您仍然只能使用客户端VM获得快速启动时间，并且仅使用服务器VM获得最高执行速度。

因此，当您有足够的可用内存并且不关心启动时间损失时，我建议将64位服务器VM用于所有内容。 32位客户端虚拟机非常适合较小的GUI应用程序，但尤其适用于平均执行时间不到一秒的小型命令行工具，或者可能需要在同一台计算机上同时运行多次。

Answer 5

32位内存地址较小。仅这一点可能会带来更好的缓存，参考位置等。

Answer 6

32位地址更少的内存空间最大理论限制是4GB但实际上在Windows系统中它是1.3GB。您可以在Linux内核上解决更多（300到400 MB）的问题。有关详细信息，请使用http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit（堆空间内存）

64位使用更高的位来寻址。所以整体内存消耗也更高。可以选择使用压缩内存指针。在http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#compressedOop

了解更多相关信息

Answer 7

64位较慢的原因是垃圾收集暂停较多。构建更多堆意味着GC在从未使用的对象清理它时需要完成更多工作。在现实生活中它意味着在构建大于12-16GB的堆时必须格外小心。如果没有微调和测量，您可以轻松地引入几分钟的完整GC暂停。

Answer 8

64位的一个论点是32位服务器硬件现在非常罕见。因此，在服务器上使用32位软件的人并不多。 32位jvms仍然存在的主要原因是支持32位客户端软件用于较旧的32位系统以及applet，这些小程序通过32位浏览器中的插件运行。

因此，如果32位版本中存在异乎寻常的漏洞，您可能是第一个发现的漏洞。这些将是在桌面系统上不太明显的错误类型，在长时间运行的服务器端软件中更明显。几周/几天后想想神秘的崩溃。内存泄漏等

所以，如果你在服务器上进行部署，除非你有充分的理由不这样做，否则几乎要去64位。在Java的内存使用和垃圾收集方面，有很多snakeoil解决方案。所以，除非你能用一些可靠的指标来支持它，否则我会谨慎地将其作为一种论证。根据我的经验，知道如何正确调整jvm的java工程师实际上非常罕见，并且大多数似乎只是在JVM_ARGS上随机复制粘贴内容，直到它有效。他们中的大多数人最终都会使用不是最佳的解决方案，不再适合他们使用的JVM，或者主动有害的解决方案。 Jvm调音是一种黑色艺术。除非你知道自己在做什么，否则最好不要乱用它。

对于客户端系统，如果需要支持applet或较旧的桌面系统，请转到32位。例如。 Windows直到最近才发布了32位版本的操作系统，Windows和osx上的许多应用仍然是32位。大多数情况下，您不必选择，在任何情况下都可以将此选择留给用户。

对于担心地址大小的人来说，64位版本可以对小于32GB的堆进行指针压缩。您需要（并且可能希望）在JVM args中启用它：-XX:+UseCompressedOops.。