Oracle JDK从6 update 23开始在64位系统上会默认开启压缩指针

如题。先前都没仔细留意，今天在看一个crash log的时候才发现这点，记录一下。
本来以为这个是在6 update 25才开始开启的…

注意：32位HotSpot VM是不支持UseCompressedOops参数的，只有64位HotSpot VM才支持。64位HotSpot VM的版本字符串样子如下：

Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode)

Sun的HotSpot VM从JDK5开始会根据运行环境来自动设定VM的一些参数（ergonomics）。其中大家最熟悉的可能是它会自动选择client与server模式、堆的初始和最大大小等。事实上ergonomics会设置非常多的内部参数，包括自动选择GC算法、并行GC的线程数、GC的工作区分块大小、对象晋升阈值等等。

Ergonomics相关的逻辑大都在hotspot/src/share/vm/runtime/arguments.cpp中，值得留意的是使用了FLAG_SET_ERGO()的地方。

于是我们可以留意一下几个版本的HotSpot对UseCompressedOops参数的处理的差异：

HotSpot 16:

#ifdef _LP64
  // Check that UseCompressedOops can be set with the max heap size allocated
  // by ergonomics.
  if (MaxHeapSize <= max_heap_for_compressed_oops()) {
    if (FLAG_IS_DEFAULT(UseCompressedOops)) {
      // Turn off until bug is fixed.
      // the following line to return it to default status.
      // FLAG_SET_ERGO(bool, UseCompressedOops, true);
    }
    // ...
  }
#endif // _LP64

HotSpot 17:

#ifndef ZERO
#ifdef _LP64
  // Check that UseCompressedOops can be set with the max heap size allocated
  // by ergonomics.
  if (MaxHeapSize <= max_heap_for_compressed_oops()) {
#ifndef COMPILER1
    if (FLAG_IS_DEFAULT(UseCompressedOops) && !UseG1GC) {
      // Disable Compressed Oops by default. Uncomment next line to enable it.
      // FLAG_SET_ERGO(bool, UseCompressedOops, true);
    }
  }
#endif
  // ...
#endif // _LP64
#endif // !ZERO

HotSpot 19 / HotSpot 20:

#ifndef ZERO
#ifdef _LP64
  // Check that UseCompressedOops can be set with the max heap size allocated
  // by ergonomics.
  if (MaxHeapSize <= max_heap_for_compressed_oops()) {
#ifndef COMPILER1
    if (FLAG_IS_DEFAULT(UseCompressedOops) && !UseG1GC) {
      FLAG_SET_ERGO(bool, UseCompressedOops, true);
    }
#endif
  }
  // ...
#endif // _LP64
#endif // !ZERO

（注：HotSpot VM的版本号与JDK的版本号之间的关系，请参考另一篇笔记：Sun/Oracle JDK、OpenJDK、HotSpot VM版本之间的对应关系）

可以看到，UseCompressedOops参数从HotSpot 19开始终于开始受ergonomics控制，会在下述条件满足的时候默认开启：
1、是64位系统（#ifdef _LP64）并且不是client VM（#ifndef COMPILER1）；
2、Java堆的最大大小不大于一个阈值（MaxHeapSize <= max_heap_for_compressed_oops()）；
3、没有通过.hotspotrc或命令行参数手动设定过UseCompressedOops参数的值；
4、没有使用Garbage-First (G1) GC。
（更新：G1 GC的限制在7017008: G1: Turn on compressed oops by default.已经解除了，于HS21 checkin，也就是说JDK7开始就没有这个限制了。）

第1、3、4点都很直观，于是第2点就是个关键点了：阈值是多大？
还是看回代码，HotSpot 20:

void set_object_alignment() {
  // Object alignment.
  assert(is_power_of_2(ObjectAlignmentInBytes), "ObjectAlignmentInBytes must be power of 2");
  MinObjAlignmentInBytes     = ObjectAlignmentInBytes;
  assert(MinObjAlignmentInBytes >= HeapWordsPerLong * HeapWordSize, "ObjectAlignmentInBytes value is too small");
  MinObjAlignment            = MinObjAlignmentInBytes / HeapWordSize;
  assert(MinObjAlignmentInBytes == MinObjAlignment * HeapWordSize, "ObjectAlignmentInBytes value is incorrect");
  MinObjAlignmentInBytesMask = MinObjAlignmentInBytes - 1;

  LogMinObjAlignmentInBytes  = exact_log2(ObjectAlignmentInBytes);
  LogMinObjAlignment         = LogMinObjAlignmentInBytes - LogHeapWordSize;

  // Oop encoding heap max
  OopEncodingHeapMax = (uint64_t(max_juint) + 1) << LogMinObjAlignmentInBytes;
}

inline uintx max_heap_for_compressed_oops() {
  // Avoid sign flip.
  if (OopEncodingHeapMax < MaxPermSize + os::vm_page_size()) {
    return 0;
  }
  LP64_ONLY(return OopEncodingHeapMax - MaxPermSize - os::vm_page_size());
  NOT_LP64(ShouldNotReachHere(); return 0);
}

（注：其中 (uint64_t(max_juint) + 1) 的值也被称为NarrowOopHeapMax，也就是2的32次方，0x100000000；
ObjectAlignmentInBytes在64位HotSpot上默认为8；
HeapWord在globalDefinitions.hpp里定义，大小跟一个char*一样；
HeapWordSize在同一个文件里定义，等于sizeof(HeapWord)，在64位系统上值为8；
LogHeapWordSize也在同一文件里，在64位系统上定义为3）
跟踪一下里面几个参数的计算，在64位HotSpot上有，

ObjectAlignmentInBytes = 8
MinObjAlignmentInBytes = 8
HeapWordSize = 8
MinObjAlignment = 1
MinObjAlignmentInBytesMask = 0x0111
LogMinObjAlignmentInBytes = 3
LogHeapWordSize = 3 // _LP64
LogMinObjAlignment = 0
OopEncodingHeapMax = 0x800000000 // 32GB

于是，前面提到的第2个条件在64位HotSpot VM上默认是：

MaxHeapSize + MaxPermSize + os::vm_page_size() <= 32GB

os::vm_page_size()是操作系统的虚拟内存的分页大小，在Linux上等于sysconf(_SC_PAGESIZE)的值；在x86_64上的Linux默认分页大小为4KB。
MaxHeapSize的值基本上等于-Xmx参数设置的值（会根据分页大小、对齐等因素做调整）。
MaxPermSize就是perm gen设置的最大大小。

注意：通过显式设置-XX:ObjectAlignmentInBytes参数到大于8的值，UseCompressedOops的应用范围可以增加。例如说-XX:ObjectAlignmentInBytes=16能让压缩指针在64GB或以下的GC heap上开启。

这值的计算也曾经RP过：

引用

Changeset: b7268662a986
Author:    coleenp
Date:      2008-04-29 19:31 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b7268662a986

6689523: max heap calculation for compressed oops is off by MaxPermSize
Summary: Need to subtract MaxPermSize from the total heap size when determining whether compressed oops is turned on.

Oracle的HotSpot VM参数文档里其实也有说UseCompressedOops的使用说明：

引用

-XX:+UseCompressedOops
Enables the use of compressed pointers (object references represented as 32 bit offsets instead of 64-bit pointers) for optimized 64-bit performance with Java heap sizes less than 32gb.

本文只是从源码层确认了该参数自动开启的条件。

这下可以确认，在我现在用的环境里，当包括perm gen在内的GC堆大小在32GB - 4KB以下的时候，使用64位的JDK 6 update 23或更高版本就会自动开启UseCompressedOops功能。

另外也记了一个gist来看默认情况下JDK6是否开启压缩指针：https://gist.github.com/rednaxelafx/1333043

在VM启动的时候，可以给 -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode 参数来确认压缩指针的工作模式。
例子请看：https://gist.github.com/rednaxelafx/998125

HotSpot VM现在只使用3种模式的压缩指针：
1、当整个GC堆所预留的虚拟地址范围的最高的地址在4GB以下的时候，使用"zero based Compressed Oops, 32-bits Oops"模式，也就是基地址为0、shift也为0；
2、当GC堆的最高地址超过了4GB，但在32GB以下的时候，使用"zero based Compressed Oops"模式，也就是基地址为0、shift为 LogMinObjAlignmentInBytes (默认为3)的模式；
3、当GC堆的最高地址超过了32GB，但整个GC堆的大小仍然在32GB以下的时候，使用非零基地址、shift为 LogMinObjAlignmentInBytes (默认为3)的模式。
如果上面三种情况都无法满足，那压缩指针就无法使用了。

上述三种模式的名字在Universe类里有声明：
hotspot/src/share/vm/memory/universe.hpp

  // Narrow Oop encoding mode:
  // 0 - Use 32-bits oops without encoding when
  //     NarrowOopHeapBaseMin + heap_size < 4Gb
  // 1 - Use zero based compressed oops with encoding when
  //     NarrowOopHeapBaseMin + heap_size < 32Gb
  // 2 - Use compressed oops with heap base + encoding.
  enum NARROW_OOP_MODE {
    UnscaledNarrowOop  = 0,
    ZeroBasedNarrowOop = 1,
    HeapBasedNarrowOop = 2
  };

可见，HotSpot VM并不尝试尽量减小shift的数值，而是使用固定数值（与对象对齐相关）或者不做shift。
这点上IBM J9 VM则采取了不同的策略，总是会尝试使用最小的shift值。

==========================================

在64位HotSpot上，不开压缩指针的时候对象头的结构是：

+0:  [ _mark (8 bytes)  ]
+8:  [ _klass (8 bytes) ]
+16: ...

开启压缩指针时：

+0:  [      _mark (8 bytes)             ]
+8:  [      _narrow_klass (4 bytes)     ]
+12: [ padding or first field (4 bytes) ]
+16: ...

==========================================

顺带记几个链接：
HotSpot早期的compressed oops的代码提交

引用

6420645: Create a vm that uses compressed oops for up to 32gb heapsizes
Summary: Compressed oops in instances, arrays, and headers. Code contributors are coleenp, phh, never, swamyv
Reviewed-by: jmasa, kamg, acorn, tbell, kvn, rasbold

引用

6689060: Escape Analysis does not work with Compressed Oops
Summary: 64-bits VM crashes with -XX:+AggresiveOpts (Escape Analysis + Compressed Oops)
Reviewed-by: never, sgoldman

引用

6711701: disable compressed oops by default

评论

1 楼 xiaoyufu007 2015-12-02  

不太明白32位指针怎么映射到64位的 还请指点~~