Question

所以，我试图运行一些简单的代码，jdk-8，通过jol输出

RootName

第一次尝试是在禁用压缩oops的情况下运行它，并在64位JVM上运行压缩klass。

    System.out.println(VMSupport.vmDetails());
    Integer i = new Integer(23);
    System.out.println(ClassLayout.parseInstance(i)
            .toPrintable());

输出，非常期待：

-XX:-UseCompressedOops -XX:-UseCompressedClassPointers

这是有道理的：8字节klass字+8字节标记字+ 4字节用于实际值，4字用于填充（对齐8字节）= 24字节。

第二次尝试使用压缩oops运行它也在64位JVM上启用了压缩klass。

同样，输出几乎可以理解：

Running 64-bit HotSpot VM.
Objects are 8 bytes aligned.

java.lang.Integer object internals:
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)                48 33 36 97 (01001000 00110011 00110110 10010111) (-1758055608)
 12     4       (object header)                01 00 00 00 (00000001 00000000 00000000 00000000) (1)
 16     4   int Integer.value                  23
 20     4       (loss due to the next object alignment)

Instance size: 24 bytes (reported by Instrumentation API)
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

4字节压缩oop（klass字）+ 8字节标记字+ 4字节值+无空间损失= 16字节。

对我来说没有意义的是这个用例：

Running 64-bit HotSpot VM.
Using compressed oop with 3-bit shift.
Using compressed klass with 3-bit shift.
Objects are 8 bytes aligned.

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)                f9 33 01 f8 (11111001 00110011 00000001 11111000) (-134138887)
 12     4   int Dummy.i                        42
 Instance size: 16 bytes (reported by Instrumentation API).

输出是这样的：

 -XX:+UseCompressedOops -XX:+UseCompressedClassPointers -XX:ObjectAlignmentInBytes=16

我真的希望两者都是“4位移位”。为什么他们不是？

修改第二个示例运行于：

 Running 64-bit HotSpot VM.
 Using compressed oop with 4-bit shift.
 Using compressed klass with 0x0000001000000000 base address and 0-bit shift.

第三个：

 XX:+UseCompressedOops -XX:+UseCompressedClassPointers

Answer 1

在查看OpenJDK代码时，很容易弄清楚这些问题的答案。

例如，grep for“UseCompressedClassPointers”，这将转到arguments.cpp：

// Check the CompressedClassSpaceSize to make sure we use compressed klass ptrs.
if (UseCompressedClassPointers) {
  if (CompressedClassSpaceSize > KlassEncodingMetaspaceMax) {
    warning("CompressedClassSpaceSize is too large for UseCompressedClassPointers");
    FLAG_SET_DEFAULT(UseCompressedClassPointers, false);
  }
}

好的，有趣的是，有“CompressedClassSpaceSize”？ Grep的定义，它在globals.hpp：

  product(size_t, CompressedClassSpaceSize, 1*G,                            \
          "Maximum size of class area in Metaspace when compressed "        \
          "class pointers are used")                                        \
          range(1*M, 3*G)                                                   \

Aha，所以类区域位于Metaspace中，占用的空间介于1 Mb和3 Gb之间。让我们来看看“CompressedClassSpaceSize”用法，因为这将把我们带到处理它的实际代码，比如metaspace.cpp：

// For UseCompressedClassPointers the class space is reserved above
// the top of the Java heap. The argument passed in is at the base of
// the compressed space.
void Metaspace::initialize_class_space(ReservedSpace rs) {

因此，压缩类被分配在Java堆外部的较小类空间中，这不需要移位 - 即使3千兆字节小到足以仅使用最低32位。

Answer 2

我将尝试对Alexey提供的答案进行一点延伸，因为有些事情可能并不明显。

根据Alexey的建议，如果我们在OpenJDK的源代码中搜索分配压缩klass位移值的位置，我们将在metaspace.cpp中找到以下代码：

void Metaspace::set_narrow_klass_base_and_shift(address metaspace_base, address cds_base) {
// some code removed 
if ((uint64_t)(higher_address - lower_base) <= UnscaledClassSpaceMax) {
  Universe::set_narrow_klass_shift(0);
} else {
  assert(!UseSharedSpaces, "Cannot shift with UseSharedSpaces");
  Universe::set_narrow_klass_shift(LogKlassAlignmentInBytes);
}

正如我们所看到的，类移位可以是0（或基本上没有移位）或3位，因为LogKlassAlignmentInBytes是globalDefinitions.hpp中定义的常量：

const int LogKlassAlignmentInBytes = 3;

所以，你的回答是：

我真的希望两者都是“4位移位”。为什么他们不是？

是ObjectAlignmentInBytes对元空间中的压缩类指针对齐没有任何影响，它始终是8bytes。

当然，这个结论并没有回答这个问题：

“为什么在使用-XX：ObjectAlignmentInBytes = 16和-XX：+ UseCompressedClassPointers时，狭窄的klass移位变为零？另外，如果没有移动，JVM如何使用32位引用引用类空间，如果堆是4GB还是更多？“

我们已经知道类空间是在java堆之上分配的，并且可以达到3G的大小。考虑到这一点，让我们做一些测试。 -XX：+ UseCompressedOops -XX：默认情况下启用UseCompressedClassPointers，因此我们可以简化这些内容。

测试1：默认值 - 8个字节对齐

$ java -XX:ObjectAlignmentInBytes=8 -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode -version

heap address: 0x00000006c0000000, size: 4096 MB, zero based Compressed Oops

Narrow klass base: 0x0000000000000000, Narrow klass shift: 3
Compressed class space size: 1073741824 Address: 0x00000007c0000000 Req Addr: 0x00000007c0000000

请注意，堆从虚拟空间中的地址0x00000006c0000000开始，大小为4GBytes。让我们从堆开始的地方跳过4Gbytes，然后我们就到了类空间开始的地方。

0x00000006c0000000 + 0x0000000100000000 = 0x00000007c0000000

类空间大小是1Gbyte，所以让我们跳过另一个1Gbyte：

0x00000007c0000000 + 0x0000000040000000 = 0x0000000800000000

我们降到32Gbytes以下。通过3位类空间移位，JVM能够引用整个类空间，尽管它处于极限（有意）。

测试2：16字节对齐

java -XX:ObjectAlignmentInBytes=16 -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode -version

heap address: 0x0000000f00000000, size: 4096 MB, zero based Compressed Oops

Narrow klass base: 0x0000001000000000, Narrow klass shift: 0
Compressed class space size: 1073741824 Address: 0x0000001000000000 Req Addr: 0x0000001000000000

这次我们可以观察到堆地址不同，但让我们尝试相同的步骤：

0x0000000f00000000 + 0x0000000100000000 = 0x0000001000000000

此时堆周围的空间刚好低于64GBytes虚拟空间边界，而类空间分配在64Gbyte边界之上。由于类空间只能使用3位移位，JVM如何引用64Gbyte以上的类空间？关键是：

Narrow klass base: 0x0000001000000000

JVM仍然使用32位压缩指针作为类空间，但是当对它们进行编码和解码时，它总是将0x0000001000000000 base添加到压缩引用而不是使用shift。请注意，只要引用的内存块低于4Gbytes（32位引用的限制），此方法就可以工作。考虑到类空间最大可以达到3G字节，我们可以轻松地在限制范围内。

3：16字节对齐，引脚堆基于8g

$ java -XX:ObjectAlignmentInBytes=16 -XX:HeapBaseMinAddress=8g -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode -version

heap address: 0x0000000200000000, size: 4096 MB, zero based Compressed Oops

Narrow klass base: 0x0000000000000000, Narrow klass shift: 3
Compressed class space size: 1073741824 Address: 0x0000000300000000 Req Addr: 0x0000000300000000

在此测试中，我们仍然保留-XX：ObjectAlignmentInBytes = 16，但还要求JVM使用-XX：HeapBaseMinAddress = 8g JVM参数在虚拟地址空间的第8 GByte分配堆。类空间将从虚拟地址空间的第12 GByte开始，3位移位足以引用它。

希望这些测试及其结果能够回答这个问题：

“为什么在使用-XX：ObjectAlignmentInBytes = 16和-XX：+ UseCompressedClassPointers时，狭窄的klass移位变为零？此外，如果堆是4GBytes或者堆，那么JVM如何引用具有32位引用的类空间？更？“

java8 -XX：+ UseCompressedOops -XX：ObjectAlignmentInBytes = 16

2 个答案: