3

我正在运行 Oracle 的 64 位 Java 1.8 Hotspot JVM。当使用不同的 GC 机制时，我一直试图围绕 JVM 的行为差异来启动压缩对象指针。例如：

$ java -XX:+UseConcMarkSweepGC -XX:+PrintFlagsFinal -Xms32766m -Xmx32766m

bool UseCompressedClassPointers        := true        {lp64_product}
bool UseCompressedOops                 := true        {lp64_product}

$ java -XX:+UseConcMarkSweepGC -XX:+PrintFlagsFinal -Xms32767m -Xmx32767m

bool UseCompressedClassPointers        = false        {lp64_product}
bool UseCompressedOops                 = false        {lp64_product}

$ java -XX:+UseG1GC -XX:+PrintFlagsFinal -Xms32736m -Xmx32736m

bool UseCompressedClassPointers        := true        {lp64_product}
bool UseCompressedOops                 := true        {lp64_product}

$ java -XX:+UseG1GC -XX:+PrintFlagsFinal -Xms32737m -Xmx32737m

bool UseCompressedClassPointers        = false        {lp64_product}
bool UseCompressedOops                 = false        {lp64_product}

我已尝试更改其他一些 G1GC 旋钮，但无法获得压缩指针优化以启动 G1 超过 32736 MB 的堆大小。但是，您可以清楚地看到，CMS 可以将压缩指针用于高达 32766 MB 的堆大小。我试图了解是什么控制了不同 GC 算法的这个阈值。

4

1 回答 1

4

但无法获得压缩指针优化以启动 32736 MB 以上的堆大小

这是正常的，因为默认情况下对象与 8 字节边界对齐，这意味着最低 3 位是冗余的，并被移位消除，这反过来意味着 32 位对象指针最多可以寻址 4GB * 8 价值的对象。

-XX:ObjectAlignmentInBytes=16如果要使用超过 32GB 的压缩 oops，则需要将对象对齐方式提高到 16 个字节。请注意，这会使小对象变大，即浪费一些内存，因此您必须衡量它是否真正为您带来任何好处。

这个答案有一些可能感兴趣的额外诊断选项。

于 2016-08-05T10:28:14.967 回答