java - JVM 压缩 Oops 背后的技巧

Question

所以我知道 HotSpot VM 现在默认启用压缩 oops。从 Java SE 6u23 开始，它通过 VM 选项 -XX:+UseCompressedOops 支持这一点。我知道它允许有效的 CPU 缓存利用，因为 CPU 缓存可以容纳比处理 64 位大小的引用更多的引用。但我不明白的是，仅使用 32 位 JVM 如何寻址多达 2⁶⁴ 个地址。

为了简化问题，我们如何仅使用 2 位来寻址最多 2⁴ 个内存地址？这种地址方案的可能编码/解码是什么？

Answer 1

有关压缩 oops 的详细说明，请参阅 "Compressed oops in the Hotspot JVM" John Rose @ Oracle 的文章。

TL;DR 版本是:

• 在现代计算机体系结构中，内存地址是字节地址，
• Java 对象引用是指向单词开头的地址¹,
• 在 64 位机器上，字对齐意味着对象引用/地址的低 3 位为零²
• 因此，通过将地址右移 3 位，我们可以将 64 位地址的最多 35 位“压缩”为 32 位字，
• 并且，可以通过向左移动 3 位来完成解压缩，这会将这 3 个零位放回去，
• 35 位寻址允许我们使用适合 64 位机器上 32 位(半)字的压缩 oops 来表示最多 32 GB 堆内存的对象指针。

---

请注意，这仅适用于 64 位 JVM。我们仍然需要能够寻址包含(最多)32 GB 堆的内存¹，这意味着 64 位硬件地址(在现代 CPU/计算机架构上)。

另请注意，这样做会受到一点惩罚；即在常规引用和压缩引用之间进行转换所需的移位指令。然而，不利的一面是消耗的实际内存较少³，因此内存缓存通常更有效。

^{1 - 这是因为现代计算机架构针对字对齐内存访问进行了优化。}

^{2 - 这假设您没有使用 -XX:ObjectAlignmentInBytes 来增加其默认(和最小)值 8 字节的对齐。}

^{3 - 事实上，内存节省是特定于应用程序的。它取决于平均对象对齐浪费、引用与非引用字段的比率等。如果您考虑调整对象对齐方式，它会变得更加复杂。}

---

To simplify the problem how can we address up to 2⁴ memory addresses using just 2 bits? What can be a possible encoding/decoding of such an address scheme?

您不能寻址 2⁴ 字节地址。但是您可以使用 2 位字地址寻址 2² 字地址(假设 32 位字)。如果您可以假设所有字节地址都是字对齐的，那么您可以通过将 4 位字节地址移动 2 位位置来将其压缩为 2 位字地址。