`
RednaxelaFX
  • 浏览: 3009180 次
  • 性别: Icon_minigender_1
  • 来自: 海外
社区版块
存档分类
最新评论

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位的 还请指点~~

相关推荐

Global site tag (gtag.js) - Google Analytics