为什么压缩Oops为对象头提供了12个字节

Question

这是继Java 6内存模型之后。在32位JVM中，对象的浅尺寸为

8 bytes (object header) + total of all instance variables + padding (optional)

如果前两个项加起来不等于8的倍数，就会有填充。

在64位JVM中，浅的大小是

16 bytes (object header) + total of all instance variables + padding (optional)

我的理解是，这个对象头由两个单词组成(oracle hotspot VM)。

• klass这个词
• 标记词

在32位JVM上，对象标头=2* 32位= 64位=8字节

在64位JVM上，对象标头=2* 64位= 128位= 16字节

但是使用CompressedOops时，3个低阶位被截断，因此在堆小于32 gigs的64位JVM上，它应该返回到8个字节。

但是当我使用JOL (Java对象布局)测试对象布局时，它显示了对象头的12个字节。

测试代码

public class App  {
    public static void main( String[] args )
    {
        System.out.println(System.getProperty("java.version"));
        System.out.println(VMSupport.vmDetails());
        System.out.println(ClassLayout.parseClass(A.class).toPrintable());
    } 
}

class A {
   int a; 
}

输出

1.8.0_05
Running 64-bit HotSpot VM.
Using compressed references with 3-bit shift.
Objects are 8 bytes aligned.
Field sizes by type: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]
Array element sizes: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]

com.layout.test.jolTesting.A object internals:
 OFFSET  SIZE  TYPE DESCRIPTION                    VALUE
      0    12       (object header)                N/A
     12     4   int A.a                            N/A
Instance size: 16 bytes (estimated, the sample instance is not available)
Space losses: 0 bytes internal + 0 bytes external = 0 bytes total

我在这里遗漏了什么来增加这些额外的4个字节呢？

Answer 1

据我所知，这是因为，与klass单词相反，标记词不是使用CompressedOops编码的。

4字节(64位压缩klass字)+8字节(标记字)= 12字节(标头)

Answer 2

HotSpot有8字节、12字节和16字节的对象头.这是因为标头包含两个部分: markword (关于对象的metainfo)和classword (对类的引用)。在32/64位模式下，标记字占用4或8个字节。Classword只是引用，因此可以在64位模式下进行压缩。

请参阅：https://shipilev.net/blog/2014/heapdump-is-a-lie/