我们知道如何制作分块堆，但使用它们会有一些开销。与32位JVM中的大堆相比，我们对存储管理的要求更快。如果你真的想要大堆，请切换到64位JVM。我们仍然需要连续的内存，但是进入64位地址空间要容易得多。
上述陈述的含义是在64位地址空间中更容易获得连续的内存。这是真的？如果是这样的话？
那是真的。进程必须从虚拟内存地址空间分配内存。其中存储代码和数据，其大小受到体系结构的寻址能力的限制。在32位进程中，您永远不能处理超过2 ^ 32个字节，不包括银行切换技巧。那是4千兆字节。在32位Windows上，操作系统通常也会占用很大一部分，例如将可寻址的VM大小减少到2千兆字节。
理想情况下，进行分配以使它们紧密地配合在一起。这在实践中很少有用。特别是共享库或DLL需要选择一个首选的加载地址，并且必须在构建库时预先猜到。
因此在实践中，分配是从现有的孔之间进行的，并且可以获得的最大可能的连续分配受最大孔的大小限制。通常远小于可寻址的VM大小，在Windows上通常大约为650兆字节。随着可用的地址空间因分配而变得分散，这往往会从那里下山。特别是通过压缩垃圾收集器移动分配的本机代码。如果您使用Windows，那么您可以使用SysInternals的VMMap实用程序深入了解VM分配。
在64位进程中，此问题完全消失。理论上可寻址的虚拟内存大小为2 ^ 64，数量巨大。如此之大以至于当前的处理器没有实现它，它们可以达到2 ^ 48。进一步受到操作系统版本的限制，并且愿意为这么多虚拟机保留页面映射表。 8TB是典型的限制。言外之意，分配之间的漏洞很大。你的程序将在它从OOM消失之前对页面文件抖动进行抨击。
我不能说明JVM是如何实现的，但从纯粹的理论角度来看，如果你有一个明显更大的虚拟地址空间（例如64位与32位相比），那么找到一个大的应该要容易得多可用于分配的连续内存块（进入极端状态 - 您无法在32位地址空间中找到连续的4GB可用内存，但很有可能在完整的64位中找到此空间地址空间）。
应该注意的是，无论虚拟地址空间大小如何，这仍然将通过（可能）非连续的物理内存页面的分配来实现，特别是如果请求的分配很大 - 更大的虚拟地址空间仅意味着存在可能是更多连续的虚拟地址可供使用。