64位虚拟机不启动指针压缩,导致-8内存对齐



maven pom.xml

<dependency>
<groupId>org.openjdk.jol</groupId>
<artifactId>jol-core</artifactId>
<version>0.10</version>
</dependency>

Java类:

public class MyObjectData {
private  int i=66;
private  long l=6L;
private String string=new String("aaaa");
}
public class ObjectTest {
@Test
public  void test1() {
Layouter l;
//64 bit vm object distribution, pointer compression not enabled
l = new HotSpotLayouter(new X86_64_DataModel());
System.out.println("***** " + l);
System.out.println(ClassLayout.parseInstance(new MyObjectData(),l).toPrintable());
System.out.println("==============================================");
}
}

运行结果:

OFFSET  SIZE               TYPE DESCRIPTION                               VALUE
0     4                    (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
4     4                    (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
8     4                    (object header)                           01 23 01 f8 (00000001 00100011 00000001 11111000) (-134143231)
12     4                    (object header)                           42 00 00 00 (01000010 00000000 00000000 00000000) (66)
16     8               long MyObjectData.l                            6
24     4                int MyObjectData.i                            66
28     4                    (alignment/padding gap)
32     8   java.lang.String MyObjectData.string                       (object)
40    -8                    (loss due to the next object alignment)
Instance size: 32 bytes
Space losses: 4 bytes internal + -8 bytes external = -4 bytes total`

我不明白为什么64位虚拟机在检查对象的内存使用情况时没有启动指针压缩,导致-8内存对齐。

我不明白为什么64位虚拟机在检查对象的内存使用情况时没有启动指针压缩。。。

JVM不会动态启动指针压缩;例如";。。。检查对象的内存使用情况时,没有启动指针压缩">

相反,它决定在(64位)JVM启动时是否使用压缩oop。它根据命令行选项进行决定;即UseCompressedOopsObjectAlignmentInBytes和最大堆大小。最大堆大小由-xmx给定,或者由特定于平台的默认算法确定。

所以。。。您需要查看JVM的(实际和默认)JVM选项,以弄清楚为什么压缩oop(显然)不起作用。使用-XX:+PrintCommandLineFlags查找。

最新更新