JVM 压缩的 Oops 背后的技巧 [英] Trick behind JVM's compressed Oops

问题描述

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

So I understand the compressed oops is enabled by default in HotSpot VM now. It has support for this from Java SE 6u23 onwards through the VM option -XX:+UseCompressedOops. I understand that it allows for efficient CPU cache utilization as the CPU caches can hold a larger number of references than if they had to deal with 64 bit sized references. But what I do not understand is how using only 32 bits JVM can address up to 2⁶⁴ addresses.

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

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

推荐答案

关于压缩 oops 的详细解释，请参见 Hotspot JVM 中的压缩 oops" 文章，作者是 John Rose @ Oracle.

For a detailed explanation of compressed oops, see the "Compressed oops in the Hotspot JVM" article by John Rose @ Oracle.

TL;DR 版本是:

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

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

Note that this only works on a 64-bit JVM. We still need to be able to address the memory containing that (up to) 32 GB heap¹, and that means 64-bit hardware addresses (on modern CPUs / computer architectures).

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

Note also that there is a small penalty in doing this; i.e. the shift instructions required to translate between regular and compressed references. However, the flip side is that less actual memory is consumed³, and memory caches are typically more effective as a consequence.

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

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

^{2 - This assumes that you haven't used -XX:ObjectAlignmentInBytes to increase the alignment from its default (and minimum) value of 8 bytes.}

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

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

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 位字地址.

You can't address 2⁴ byte addresses. But you can address 2² word addresses (assuming 32-bit words) using 2-bit word addresses. If you can assume that all byte addresses are word-aligned, then you can compress a 4-bit byte address as 2-bit word address by shifting it by 2-bit positions.

这篇关于JVM 压缩的 Oops 背后的技巧的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！