Java 如何在JVM中实现压缩ooP？

谷歌的快速搜索结果出人意料地一无所获

我的问题如下:

对于32位体系结构，2^32字节将是内存空间=4GB 因此，对于4GB的Java堆，我们需要一个大小为32位=4字节的指针

然而，根据压缩oop的概念，JVM仍然可以使用4字节指针，最大堆大小为32GB

仔细想想，32GB=4GB*2^3。 这意味着我们实际上还需要3个比特，但不知何故，这些比特在存储/访问期间被JVM编码/解码

我发现这些页面无法访问：

有人能给我解释一下幕后发生的魔法吗

对Mods：我发现了一个存在的问题，但这指向了。这个维基已经不存在了，你能允许这个问题持续很长时间，以至于有人给我指向另一个深度链接吗。求你了

编辑：

@Markus Mikkolainen的回答是我发现的最简单、最简单的解释： 它们是偏移量，用于索引8字节块而不是1字节块，因为对象是8字节对齐的。

---

这是否回答了您的问题，它们是偏移量，用于索引8字节块而不是1字节块，因为对象是8字节对齐的

我在发布后找到了链接-在Windows 32位中，您只有1.2-1.5 GB的连续虚拟内存可用。在Java8中，您可以使用32位引用寻址高达64GB的堆。它将对象对齐从8字节增加到16字节。如果我是正确的，这是否意味着java对象在堆上的最小大小将是16字节？（因为从第9个字节开始的对象在内存中是不可表示的？）我想说的是，一个对象将使用的最小空间是16个字节，包括头和对象对齐。如果您使用

-XX:-UseTLAB

关闭TLAB，您可以看到每个对象分配的确切空间量。更正您需要32 GB。这是一个非常愚蠢的问题：因为32位系统可以访问2^32个对象，即内存位置，而32位处理器的字大小为32位=32数据线=4字节，为什么RAM限制为2^32*8位=4 GB，而不是2^32*32位。是因为操作系统希望一次写入一个字节，而不是一次写入4个字节（以防止对象对齐造成内存浪费）？由于向后兼容性，硬件可以在任何地方读取一个字节，但是这样做效率很低。@MarkusMikkolainen你在上面的评论中对我的查询是肯定的吗？它与操作系统无关，它与英特尔体系结构和缓存等有关。哦，对了，所以我将重新提出我的问题：为什么RAM限制在2^32*8位=4 GB，而不是2^32*32位。是因为处理器希望能够一次读/写一个字节，而不是一次读/写4个字节（以防止由于对象对齐而造成内存浪费）