性能文章>06 “eden没有发生minor gc, 对象直接分配在了old gen“ 的调试>

06 “eden没有发生minor gc, 对象直接分配在了old gen“ 的调试原创

1年前
286945

前言

呵呵 最近在看这样一篇文章的时候, eden区没有发生minor gc,对象直接分配在了old gen 

看到了 R大 的叱咤风云, 讲解的非常细致, 十分令人佩服, 然后 若是想有所收获, 还得 构造一下这个情况, 复现一下, 然后 调试着走一次, 才能 有所收获, 嘿嘿 

当然 由于 vm 版本不一样, 因此 下面的测试用例的相关 选项 我这里做了一些 调整 一下代码, 截图 基于 jdk9 

测试用例如下 

package com.hx.test04;

/**
 * AllocationTest
 *
 * @author Jerry.X.He <970655147@qq.com>
 * @version 1.0
 * @date 2020-03-06 15:24
 */
public class Test03AllocationTest {

  /**
   * constants
   */
  private static final int _1KB = 1024;
  private static final int _1MB = _1KB * 1024;

  // Test03AllocationTest
  // refer : https://hllvm-group.iteye.com/group/topic/38293
  /**
   * -Xint -Xmx100M -XX:+UseParallelGC -XX:-UseTLAB -XX:+PrintGCDetails -XX:MaxNewSize=40M -XX:NewSize=28M
   */
  public static void main(String[] args) {

    testAllocation();

  }

  // testAllocation
  public static void testAllocation() {

    byte[] byte1 = new byte[_1MB*5];
    byte[] byte2 = new byte[_1MB*10];
    byte1 = null;
    byte2 = null;

    byte[] byte3 = new byte[_1MB*5];
    byte[] byte4 = new byte[_1MB*10];
    byte3 = null;
    byte4 = null;

    byte[] byte5 = new byte[_1MB*15];

  }

}

跑的时候 需要加上 如上的相关 vm 参数, 但是 普通的 跑这个 测试用例 看不到太多的东西, 需要结合 具体的调试, 才能 了解到 R大 所说的一系列描述的意思  

第一个字节数组的数据分配 

可以看到, 这里是 第一个 "new byte[_1MB*5]", length 为 5M, size 怎么看起来和 length 没什么关系啊 ? 
呵呵 我最开始看到这里也奇怪, 直到看了一下 "size_t size = typeArrayOopDesc::object_size(layout_helper(), length);" 的代码 

原来这里的 size = (length + header_size) / WordPerBytes 计算出来的, BytesPerWord 是指一个字对应多少个字节, 64位操作系统中其值为 8 

呵呵 我最开始看觉得有些奇怪是因为 我发现这个 size 怎么比 length 大这么多??, 不就装字节数据 + mark + klass + length 么, 咋个会多出这么多, 后来仔细一看原来 size 是比 length 少了一位。

第一次字节数组的分配细节 

分配之前 young_gen 的 used 为 4.18M, capacity 为 24.50M(eden:21M, from:3.5M)

eden 的 used 为 4.18M, capacity 为 21M 

我们这里分配的是 5M, 可以分配, 就直接从 young_gen 里面分配了 

创建第一个字节数组之后 young_gen used 为 9.18M 

第二次数组分配的细节 

分配之前 young_gen 的 used 为 9.18M, capacity 为 24.50M(eden:21M, from:3.5M)

eden 的 used 为 9.18M, capacity 为 21M 

堆的相关数据 和 第一次数组分配之后的结果一样, 只是这里需要分配的字节数组 变成了 10M 

这里 young_gen 依然能够分配第二个数组 

分配之后 young_gen used 为 19.18M 

第三次数组分配的细节  

分配之前 young_gen 的 used 为 19.18M, capacity 为 24.50M(eden:21M, from:3.5M)

eden 的 used 为 19.18M, capacity 为 21M 

到这里 young_gen 分配不了 这个 5M 的字节数组了 

后面尝试 在 young_gen 再重新分配, 失败 

尝试在 old_gen 分配空间, 不满足条件 

gc_locker_stalled_count, GCLocker::is_active_and_needs_gc 也不满足条件 

尝试在 old_gen 分配空间的条件如下 

这里的 GCLocker::is_active_and_needs_gc 和 _death_march_count 在这里不满足条件 

R大 评论中也是这个判断, 只是由于 版本不一样, 细节上存在一些差异 

然后触发了一次 minor gc 

VM_ParallelGCFailedAllocation 处理了之后 为第三个字节数组 分配了空间 

分配之后 eden 的 used 为 5.00M 

第四次数组分配细节如下 

分配之前 young_gen 的 used 为 5.00M, capacity 为 24.50M(eden:21M, from:3.5M)

eden 的 used 为 5.00M, capacity 为 21M 

可以明显看到 eden 是足以分配 这个 10M 的字节数组的, 因此这里 就在 young_gen 分配 

分配之后 eden 的 used 为 15.00M 

第五次数组分配的细节

分配之前 young_gen 的 used 为 15.00M, capacity 为 24.50M(eden:21M, from:3.5M)

eden 的 used 为 15.00M, capacity 为 21M 

在 young_gen 已经分配不下 这里的 15M 的数组 

根据上面的 是否需要在 old_gen 分配的条件之一, "size > eden_space.capacity_in_words/2", 来比较的话 

我们这里 size 是 1966082, eden_space.capacity_in_words/2 为 1376256, 是符合 在 old_gen 分配的条件的, 因此 这里第五个 字节数组 就在 old_gen 分配了 

这上面的 比较还可以换一个方式, 上面的比较的单位是 字, 我们换成字节的话 会更清晰一些, eden 的空间是 21 M, 一半为 10.5M, 然后 这里申请的空间为 15M, 15M > 10.5M, 因此 可以在 old_gen 里面分配 

引用

eden区没有发生minor gc,对象直接分配在了old gen

点赞收藏
分类:标签:
黄金键盘
请先登录,查看4条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

随机一门技术分享之Netty

随机一门技术分享之Netty

从 Linux 内核角度探秘 JDK MappedByteBuffer

从 Linux 内核角度探秘 JDK MappedByteBuffer

MappedByteBuffer VS FileChannel:从内核层面对比两者的性能差异

MappedByteBuffer VS FileChannel:从内核层面对比两者的性能差异

5
4