性能文章>G1之REGION SIZE>

G1之REGION SIZE原创

1年前
546306

说明:JDK7和JDK8的Region划分实现略有不同(差异非常小,且只有-Xmx和-Xms的值不一样才有区别),本篇文章讲解的是JDK8中Region的划分实现。

源码分析

G1 Region划分的实现源码在headpRegion.cpp中,摘取部分核心源码如下:

// Minimum region size; we won't go lower than that.
// We might want to decrease this in the future, to deal with small
// heaps a bit more efficiently.
#define MIN_REGION_SIZE  (      1024 * 1024 )

// Maximum region size; we don't go higher than that. There's a good
// reason for having an upper bound. We don't want regions to get too
// large, otherwise cleanup's effectiveness would decrease as there
// will be fewer opportunities to find totally empty regions after
// marking.
#define MAX_REGION_SIZE  ( 32 * 1024 * 1024 )

// The automatic region size calculation will try to have around this
// many regions in the heap (based on the min heap size).
#define TARGET_REGION_NUMBER          2048

size_t HeapRegion::max_region_size() {
  return (size_t)MAX_REGION_SIZE;
}

// 这个方法是计算region的核心实现
void HeapRegion::setup_heap_region_size(size_t initial_heap_size, size_t max_heap_size) {
  uintx region_size = G1HeapRegionSize;
  // 是否设置了G1HeapRegionSize参数,如果没有配置,那么按照下面的方法计算;如果设置了G1HeapRegionSize就按照设置的值计算
  if (FLAG_IS_DEFAULT(G1HeapRegionSize)) {
    // average_heap_size即平均堆的大小,(初始化堆的大小即Xms+最大堆的大小即Xmx)/2
    size_t average_heap_size = (initial_heap_size + max_heap_size) / 2;
    // average_heap_size除以期望的REGION数量得到每个REGION的SIZE,与MIN_REGION_SIZE取两者中的更大值就是实际的REGION_SIZE;从这个计算公式可知,默认情况下如果JVM堆在2G(TARGET_REGION_NUMBER*MIN_REGION_SIZE)以下,那么每个REGION_SIZE都是1M;
    region_size = MAX2(average_heap_size / TARGET_REGION_NUMBER, (uintx) MIN_REGION_SIZE);
  }

  // region_size的对数值
  int region_size_log = log2_long((jlong) region_size);
  // 重新计算region_size,确保它是最大的小于或等于region_size的2的N次方的数值,例如重新计算前region_size=33,那么重新计算后region_size=32;重新计算前region_size=16,那么重新计算后region_size=16;
  // Recalculate the region size to make sure it's a power of
  // 2. This means that region_size is the largest power of 2 that's
  // <= what we've calculated so far.
  region_size = ((uintx)1 << region_size_log);

  // 确保计算出来的region_size不能比MIN_REGION_SIZE更小,也不能比MAX_REGION_SIZE更大
  // Now make sure that we don't go over or under our limits.
  if (region_size < MIN_REGION_SIZE) {
    region_size = MIN_REGION_SIZE;
  } else if (region_size > MAX_REGION_SIZE) {
    region_size = MAX_REGION_SIZE;
  }

  // 与MIN_REGION_SIZE和MAX_REGION_SIZE比较后,再次重新计算region_size
  // And recalculate the log.
  region_size_log = log2_long((jlong) region_size);

  ... ...
}

源码解读:

MIN_REGION_SIZE:允许的最小的REGION_SIZE,即1M,不可能比1M还小;
MAX_REGION_SIZE:允许的最大的REGION_SIZE,即32M,不可能比32M更大;限制最大REGION_SIZE是为了考虑GC时的清理效果;
TARGET_REGION_NUMBER:JVM对堆期望划分的REGION数量,而不是实际划分的REGION数量;

计算演示

1、 验证下面这段源码,即如果配置了XX:G1HeapRegionSize,那么以配置为准;否则以计算为准:

// JDK8的实现
if (FLAG_IS_DEFAULT(G1HeapRegionSize)) {
  size_t average_heap_size = (initial_heap_size + max_heap_size) / 2;
  region_size = MAX2(average_heap_size / TARGET_REGION_NUMBER, (uintx) MIN_REGION_SIZE);
}


// JDK7的实现
if (FLAG_IS_DEFAULT(G1HeapRegionSize)) {
  // We base the automatic calculation on the min heap size. This
  // can be problematic if the spread between min and max is quite
  // wide, imagine -Xms128m -Xmx32g. But, if we decided it based on
  // the max size, the region size might be way too large for the
  // min size. Either way, some users might have to set the region
  // size manually for some -Xms / -Xmx combos.

  region_size = MAX2(min_heap_size / TARGET_REGION_NUMBER,
                     (uintx) MIN_REGION_SIZE);
}

这是JDK7和JDK8关于REGION_SIZE计算唯一的区别,事实上当Xmx和Xms的值不一样时,JVM不太好自动计算region_size,JDK7的注释进一步的解释了,且建议某些-Xms/-Xmx组合情况下,用户自己设置REGION_SIZE

计算为准

假设配置JVM参数-Xmx6144m -Xms2048m,那么计算过程如下:

  • average_heap_size=(6144m+2048m)/2=4096m
  • region_size=max(4096m/2048, 1m)=2m
  • region_size_log=21(因为2^21=210241024<=2m)
  • region_size=2^21=2m(保证region_size的值为2^n)
  • region_size=2m(因为MIN_REGION_SIZE<=2m<=MAX_REGION_SIZE)

配置为准

假设配置JVM参数-Xmx1024m -Xms1024m -XX:G1HeapRegionSize=4m,那么计算过程如下:

  • region_size=4m
  • region_size_log=22(因为2^22<=4m)
  • region_size=2^22=4m
  • region_size=4m(因为MIN_REGION_SIZE<=1m<=MAX_REGION_SIZE)
    2、 验证下面这段源码,即region_size的值一定是2^n:

int region_size_log = log2_long((jlong) region_size);
region_size = ((uintx)1 << region_size_log);
假设配置JVM参数-Xmx3072m -Xms3072m,那么计算过程如下:

  1. average_heap_size=(3072m+3072m)/2=3072m
  2. region_size=max(3072m/2048, 1m)=1.510241024
  3. region_size_log=20(因为2^20<1.510241024<2^21)
  4. region_size=2^20=1m(保证region_size的值为2^n)
  5. region_size=1m(因为MIN_REGION_SIZE<=1m<=MAX_REGION_SIZE)

3、 验证下面这段源码,即region_size的值一定是在[MIN_REGION_SIZE, MAX_REGION_SIZE]这个范围:

if (region_size < MIN_REGION_SIZE) {
  region_size = MIN_REGION_SIZE;
} else if (region_size > MAX_REGION_SIZE) {
  region_size = MAX_REGION_SIZE;
}

假设配置JVM参数-Xmx1024m -Xms1024m -XX:G1HeapRegionSize=64m,那么计算过程如下:

  1. region_size=64m
  2. region_size_log=26(因为2^26<=64m)
  3. region_size=2^26=64m
  4. region_size=32m(因为region_size必须在[MIN_REGION_SIZE, MAX_REGION_SIZE]之间)

REGION_SIZE总结

通过上面的分析可知G1垃圾回收时JVM分配REGION的SIZE有如下要求:
1、如果配置了-XX:G1HeapRegionSize,那么先以配置的值为准;否则以计算为准;
2、根据第一步计算得到的REGION_SIZE,取不能大于它的最大的2^n的值为第二步计算得到的REGION_SIZE的值
3、把第二步计算得到的REGION_SIZE和MIN_REGION_SIZE比较,如果比MIN_REGION_SIZE还小,那么MIN_REGION_SIZE就是最终的region_size;否则再把REGION_SIZE和MAX_REGION_SIZE比较,如果比MAX_REGION_SIZE还大,那么MAX_REGION_SIZE就是最终的region_size;如果REGION_SIZE在[MIN_REGION_SIZE, MAX_REGION_SIZE]之间,那么REGIOIN_SIZE就是最终的region_size;

验证方式

通过下面这段源码配置JVM参数即可验证JDK8 G1中REGION_SIZE的计算方式:

import java.util.UUID;

/**
 * @author afei
 */
public class StringTest {
    public static void main(String[] args) throws Exception {
        for (int i=0; i<Integer.MAX_VALUE; i++){
            // 利用UUID不断生成字符串,这些字符串都会在堆中分配,导致不断塞满Eden区引起YoungGC
            UUID.randomUUID().toString();
            if (i>=100000 && i%100000==0){
                System.out.println("i="+i);
                Thread.sleep(3000);
            }
        }
        Thread.sleep(3000);
    }
}

JVM参数:

java -XX:+UseG1GC -verbose:gc ${HEAP_OPTS} -XX:+PrintHeapAtGC StringTest,其中${HEAP_OPTS}由上面计算演示过程中提供的JVM参数取代即可,例如:java -XX:+UseG1GC -verbose:gc -Xmx6144m -Xms2048m -XX:+PrintHeapAtGC StringTest,GC日志如下,从GC日志中可以看出region size为2048k:

i=100000
{Heap before GC invocations=0 (full 0):
 garbage-first heap   total 2097152K, used 104448K [0x0000000640000000, 0x0000000640202000, 0x00000007c0000000)
  region size 2048K, 51 young (104448K), 0 survivors (0K)
 Metaspace       used 2863K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 308K, capacity 386K, committed 512K, reserved 1048576K
[GC pause (G1 Evacuation Pause) (young) 102M->440K(2048M), 0.0093728 secs]
Heap after GC invocations=1 (full 0):
 garbage-first heap   total 2097152K, used 440K [0x0000000640000000, 0x0000000640202000, 0x00000007c0000000)
  region size 2048K, 1 young (2048K), 1 survivors (2048K)
 Metaspace       used 2863K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 308K, capacity 386K, committed 512K, reserved 1048576K
}
i=200000
... ...
请先登录,感受更多精彩内容
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得