jvm源码阅读笔记[3]：从内存分配到触发GC的细节

    从零开始看源码，旨在从源码验证书上的结论，探索书上未知的细节。有疑问欢迎留言探讨
    个人源码地址：https://github.com/FlashLightNing/openjdk-notes
    还有一个openjdk6,7,8,9的地址：https://github.com/dmlloyd/openjdk
    jvm源码阅读笔记[1]：如何触发一次CMS回收
    jvm源码阅读笔记[2]：你不知道的晋升阈值TenuringThreshold详解
    jvm源码阅读笔记[3]：从内存分配到触发GC的细节
    jvm源码阅读笔记[4]：从GC说到vm operation
    jvm源码阅读笔记[5]：内存分配失败触发的GC究竟对内存做了什么？

    
    除了第一篇说到的，对于使用cms回收的应用，会有线程轮询判断老年代是否满足GC的条件，若满足，则会触发一次cms老年代的回收。
    针对年轻代，更常见的是，线程优先在eden区分配对象的时候，若eden区空间不足，则会触发一次young gc。若不允许担保失败，则还可能转为一次full gc。那么，今天就来看看这种内存分配不足触发GC的过程。
    以下是collectedHeap.inline.hpp中的分配的代码。
    

oop CollectedHeap::obj_allocate(KlassHandle klass, int size, TRAPS) {  debug_only(check_for_valid_allocation_state());  assert(!Universe::heap()->is_gc_active(), "Allocation during gc not allowed");//校验在GC的时候不会进行内存分配  assert(size >= 0, "int won't convert to size_t");  HeapWord* obj = common_mem_allocate_init(klass, size, CHECK_NULL);  post_allocation_setup_obj(klass, obj, size);  NOT_PRODUCT(Universe::heap()->check_for_bad_heap_word_value(obj, size));  return (oop)obj;}

    
    collectedHeap定义了Java堆的实现，定义了堆必须实现的功能，如创建TLAB,内存分配等基本功能。然后其他类通过继承collectedHeap类，实现了几种具体的堆类型，主要有ParallelScavengeHeap，G1CollectedHeap等。这些细节以后再写。
    从源码中可以看到，首先是一些简单的校验，如当前堆不处于GC状态，分配的大小>0。然后再调用common_mem_allocate_init方法进行内存分配，再是调用post_allocation_setup_obj做一些初始化的工作，如设置对象头信息等。
    来看看common_mem_allocate_init方法：
    

HeapWord* CollectedHeap::common_mem_allocate_init(KlassHandle klass, size_t size, TRAPS) {  HeapWord* obj = common_mem_allocate_noinit(klass, size, CHECK_NULL);  init_obj(obj, size);//字节填充和对齐  return obj;}

    
    它先是调用common_mem_allocate_noinit方法申请了内存空间，然后调用init_obj方法进行初始化，这里的初始化主要是为申请出来的这块空间填充0字节和字节对齐。
    还是来看看common_mem_allocate_noinit方法吧。
    

HeapWord* CollectedHeap::common_mem_allocate_noinit(KlassHandle klass, size_t size, TRAPS) {  CHECK_UNHANDLED_OOPS_ONLY(THREAD->clear_unhandled_oops();)  if (HAS_PENDING_EXCEPTION) {    NOT_PRODUCT(guarantee(false, "Should not allocate with exception pending"));    return NULL;  // caller does a CHECK_0 too  }  HeapWord* result = NULL;  if (UseTLAB) {//在tlab里分配    result = allocate_from_tlab(klass, THREAD, size);    if (result != NULL) {      assert(!HAS_PENDING_EXCEPTION,             "Unexpected exception, will result in uninitialized storage");      return result;    }  }  bool gc_overhead_limit_was_exceeded = false;   //在堆中分配  result = Universe::heap()->mem_allocate(size,                                          &gc_overhead_limit_was_exceeded);  if (result != NULL) {    NOT_PRODUCT(Universe::heap()->      check_for_non_bad_heap_word_value(result, size));    assert(!HAS_PENDING_EXCEPTION,           "Unexpected exception, will result in uninitialized storage");    THREAD->incr_allocated_bytes(size * HeapWordSize);    AllocTracer::send_allocation_outside_tlab_event(klass, size * HeapWordSize);    return result;  }    //抛出OOM异常  if (!gc_overhead_limit_was_exceeded) {    // -XX:+HeapDumpOnOutOfMemoryError and -XX:OnOutOfMemoryError support    report_java_out_of_memory("Java heap space");    if (JvmtiExport::should_post_resource_exhausted()) {      JvmtiExport::post_resource_exhausted(        JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP,        "Java heap space");    }    THROW_OOP_0(Universe::out_of_memory_error_java_heap());  } else {    // -XX:+HeapDumpOnOutOfMemoryError and -XX:OnOutOfMemoryError support    report_java_out_of_memory("GC overhead limit exceeded");    if (JvmtiExport::should_post_resource_exhausted()) {      JvmtiExport::post_resource_exhausted(        JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP,        "GC overhead limit exceeded");    }    THROW_OOP_0(Universe::out_of_memory_error_gc_overhead_limit());  }}

    
    可以看到分配分为3步，

1. 若开启了UseTLAB,则在tlab里面分配，分配成功则返回对象空间。若分配失败，则返回null
2. 若第一步返回的是null,则在堆中进行分配
3. 若仍分配失败，则抛出OOM异常。

    
    先来看看第一个开启了UseTLAB的情况：
    

HeapWord* CollectedHeap::allocate_from_tlab(KlassHandle klass, Thread* thread, size_t size) {  assert(UseTLAB, "should use UseTLAB");  //第一步：直接在线程的tlab上分配，若分配失败，则走相对慢的分配：allocate_from_tlab_slow  HeapWord* obj = thread->tlab().allocate(size);  if (obj != NULL) {    return obj;  }  /*   是指当直接在线程的tlab上分配不下的时候，线程重新申请一块tlab,然后在这块tlab上分配，并返回分配完的地址。  但如果剩余的空间>配置的可浪费的空间，则就不在tlab分配，而是去eden区分配  */  return allocate_from_tlab_slow(klass, thread, size);}

    
    首先在线程的tlab上通过指针碰撞分配，若剩余空间大于要分配的size，则进行分配。若空间不足，则调用allocate_from_tlab_slow进行分配。该方法中线程重新申请了一块tlab然后在该tlab上分配。来看看这个方法：
    

HeapWord* CollectedHeap::allocate_from_tlab_slow(KlassHandle klass, Thread* thread, size_t size) {  /*   如果在tlab上的空闲空间大于设置的能忽略的大小，那就不在tlab上分配，而是在堆的共享区域，保留该tlab，用于下次分配使用。  */   if (thread->tlab().free() > thread->tlab().refill_waste_limit()) {    thread->tlab().record_slow_allocation(size);    return NULL;  }  /*    忽略此tlab然后重新申请一块。为了最小化内存碎片，最后一个tlab可能比其他的都小  */  size_t new_tlab_size = thread->tlab().compute_size(size);  thread->tlab().clear_before_allocation();  if (new_tlab_size == 0) {    return NULL;  }  // 申请一个新的tlab  HeapWord* obj = Universe::heap()->allocate_new_tlab(new_tlab_size);  if (obj == NULL) {    return NULL;  }  AllocTracer::send_allocation_in_new_tlab_event(klass, new_tlab_size * HeapWordSize, size * HeapWordSize);  if (ZeroTLAB) {    Copy::zero_to_words(obj, new_tlab_size);  } else {#ifdef ASSERT    size_t hdr_size = oopDesc::header_size();    Copy::fill_to_words(obj + hdr_size, new_tlab_size - hdr_size, badHeapWordVal);#endif // ASSERT  }  thread->tlab().fill(obj, obj + size, new_tlab_size);  return obj;}

    
    可以看到，当tlab中剩余空间>设置的可忽略大小以及申请一块新的tlab失败时返回null,然后走上面的第二步，也就是在堆的共享区域分配。当tlab剩余空间可以忽略，则申请一块新的tlab，若申请成功，则在此tlab上分配。
    再来看看分配的几个步骤

1. 若开启了UseTLAB,则在tlab里面分配，分配成功则返回对象空间。若分配失败，则返回null
2. 若第一步返回的是null,则在堆中进行分配
3. 若仍分配失败，则抛出OOM异常。

    总结起来第一步就是：若开启了tlab,则先通过指针碰撞在线程的tlab分配。若在当前线程的tlab分配不下，则判断tlab剩余空间能否忽略。若能忽略，则忽略此tlab然后重新申请一块tlab。若不能忽略，或者申请tlab失败，则返回null。若申请了tlab后分配成功，则返回分配完的空间。若返回的是null,则接下来需要在堆的共享区域内分配（tlab虽然也在堆中，但是线程各自的，并不是共享的）。

    接下来我们看看第二步:在堆中进行分配。主要是mem_allocate方法。
    

HeapWord* GenCollectorPolicy::mem_allocate_work(size_t size,                                        bool is_tlab,                                        bool* gc_overhead_limit_was_exceeded) {  GenCollectedHeap *gch = GenCollectedHeap::heap();  debug_only(gch->check_for_valid_allocation_state());  assert(gch->no_gc_in_progress(), "Allocation during gc not allowed");  /*    一般来说，gc_overhead_limit_was_exceeded=false。   只有当gc 时间限制超过了下面的检查时才会设置成true.  */   *gc_overhead_limit_was_exceeded = false;  HeapWord* result = NULL;   for (int try_count = 1, gclocker_stalled_count = 0; /* return or throw */; try_count += 1) {    HandleMark hm;     // .第一次尝试分配不需要获取锁，通过while+CAS来保障    Generation *gen0 = gch->get_gen(0);//年轻代    assert(gen0->supports_inline_contig_alloc(),      "Otherwise, must do alloc within heap lock");    if (gen0->should_allocate(size, is_tlab)) {//对大小进行判断，比如是否超过eden区能分配的最大大小      result = gen0->par_allocate(size, is_tlab);//while循环+指针碰撞+CAS分配，      if (result != NULL) {        assert(gch->is_in_reserved(result), "result not in heap");        return result;      }    }    //如果res=null,表示在eden区分配失败了，因为没有连续的空间。则继续往下走    unsigned int gc_count_before;      {      MutexLocker ml(Heap_lock);//获取锁      if (PrintGC && Verbose) {        gclog_or_tty->print_cr("TwoGenerationCollectorPolicy::mem_allocate_work:"                      " attempting locked slow path allocation");      }      //需要注意的是，只有大对象可以被分配在老年代。一般情况下都是false,所以first_only=true      bool first_only = ! should_try_older_generation_allocation(size);      result = gch->attempt_allocation(size, is_tlab, first_only);//在每个代尝试分配，first_only=true时只会在年轻代分配      if (result != NULL) {        assert(gch->is_in_reserved(result), "result not in heap");        return result;      }      /*Gc操作已被触发但还无法被执行,一般不会出现这种情况，只有在jni中jni_GetStringCritical等方法被调用时出现is_active_and_needs_gc=TRUE，主要是为了避免GC导致对象地址改变。jni_GetStringCritical方法的作用参考文章：http://blog.csdn.net/xyang81/article/details/42066665      */      if (GC_locker::is_active_and_needs_gc()) {          if (is_tlab) {          return NULL;  // Caller will retry allocating individual object        }        if (!gch->is_maximal_no_gc()) {//因为不能进行GC回收，所以只能尝试通过扩堆          result = expand_heap_and_allocate(size, is_tlab);          if (result != NULL) {            return result;          }        }        /*        Number of times to retry allocations when "                      \          "blocked by the GC locker         GCLockerRetryAllocationCount 默认值=2        */        if (gclocker_stalled_count > GCLockerRetryAllocationCount) {          return NULL; // we didn't get to do a GC and we didn't get any memory        }        JavaThread* jthr = JavaThread::current();        if (!jthr->in_critical()) {          MutexUnlocker mul(Heap_lock);          // Wait for JNI critical section to be exited          GC_locker::stall_until_clear();          gclocker_stalled_count += 1;          continue;        } else {          if (CheckJNICalls) {            fatal("Possible deadlock due to allocating while"                  " in jni critical section");          }          return NULL;        }      }      gc_count_before = Universe::heap()->total_collections();    }    VM_GenCollectForAllocation op(size, is_tlab, gc_count_before);//VM操作进行一次由分配失败触发的GC    VMThread::execute(&op);    if (op.prologue_succeeded()) { //一次GC操作已完成        result = op.result();      if (op.gc_locked()) {//当前线程没有成功触发GC(可能刚被其它线程触发了),则继续重试分配           assert(result == NULL, "must be NULL if gc_locked() is true");         continue;  // retry and/or stall as necessary 重试分配      }      /*       分配失败且已经完成GC了，则判断是否超时等信息。       */      const bool limit_exceeded = size_policy()->gc_overhead_limit_exceeded();      const bool softrefs_clear = all_soft_refs_clear();      if (limit_exceeded && softrefs_clear) {        *gc_overhead_limit_was_exceeded = true;        size_policy()->set_gc_overhead_limit_exceeded(false);        if (op.result() != NULL) {          CollectedHeap::fill_with_object(op.result(), size);        }        return NULL;      }      assert(result == NULL || gch->is_in_reserved(result),             "result not in heap");      return result;    }    // Give a warning if we seem to be looping forever.    if ((QueuedAllocationWarningCount > 0) &&        (try_count % QueuedAllocationWarningCount == 0)) {          warning("TwoGenerationCollectorPolicy::mem_allocate_work retries %d times \n\t"                  " size=" SIZE_FORMAT " %s", try_count, size, is_tlab ? "(TLAB)" : "");    }  }  //for循环结束}

    
    该方法比较长，主要分为以下几步：
    1.先判断是否在年轻代设置了最大能分配的大小。若没设置（默认没设置）或者此处分配的大小<设置的最大能分配的大小，则通过while+CAS的方式无锁在eden区分配。否则，进入第二步的分配
    2.先获取堆锁，然后判断此次分配能否在old区分配。接下来，根据判断的结果在堆的年轻代和老年代分配。
    3.如果第二步分配失败，判断此时有没有jni_GetStringCritical等JNI方法被调用。若有JNI调用，因为无法GC（可参考http://blog.csdn.net/xyang81/article/details/42066665），所以只能判断能否扩堆。若能扩堆则扩堆。若不能扩堆，因为最外层是for循环，则跳过此处循环进行下次循环。
    4.若3仍然失败了，则通过VM触发一次由分配失败触发的一次GC，也就是我们经常能在GC日志里面看到的“_allocation_failure”。具体VM触发的GC的细节下篇文章再做具体的描述。

    来看看第2步中JVM是怎么判断对象能否在Old区分配的：
    

bool GenCollectorPolicy::should_try_older_generation_allocation(        size_t word_size) const {  GenCollectedHeap* gch = GenCollectedHeap::heap();  size_t gen0_capacity = gch->get_gen(0)->capacity_before_gc();//eden大小+from大小  return    (word_size > heap_word_size(gen0_capacity))         || GC_locker::is_active_and_needs_gc()         || gch->incremental_collection_failed();}

    
    只要以下3个条件满足一个，就可以在old区分配对象:

1. 要分配的大小>年轻代容量（eden+from总大小）
2. 某些JNI方法正在被调用
3. 最近发生过一次担保失败或者可能发生担保失败

    总结起来，分配分为3个大步骤：

1. 若开启了UseTLAB,则在tlab里面分配，分配成功则返回对象空间。若分配失败，则返回null
2. 若第一步返回的是null,则在堆中进行分配
3. 若仍分配失败，则抛出OOM异常。

    具体细节来讲，第一步做的是：若开启了tlab,则先通过指针碰撞在线程的tlab分配。若在当前线程的tlab分配不下，则判断tlab剩余空间能否忽略。若能忽略，则忽略此tlab然后重新申请一块tlab。若不能忽略，或者申请tlab失败，则返回null。若申请了tlab后分配成功，则返回分配完的空间。若返回的是null,则接下来需要在堆的共享区域内分配（tlab虽然也在堆中，但是线程各自的，并不是共享的）。
    第二步具体的是：
    1.先判断是否在年轻代设置了最大能分配的大小。若没设置（默认没设置）或者此处分配的大小<设置的最大能分配的大小，则通过while+CAS的方式无锁在eden区分配。否则，进入第二步的分配
    2.先获取堆锁，然后判断此次分配能否在old区分配。接下来，根据判断的结果在堆的年轻代和老年代分配。
    3.如果第二步分配失败，判断此时有没有jni_GetStringCritical等JNI方法被调用。若有JNI调用，因为无法GC，所以只能判断能否扩堆。若能扩堆则扩堆。若不能扩堆，因为最外层是for循环，则跳过此处循环进行下次循环。
    4.若3仍然失败了，则通过VM触发一次由分配失败触发的一次GC，也就是我们经常能在GC日志里面看到的“_allocation_failure”。

    

    从零开始看源码，旨在从源码验证书上的结论，探索书上未知的细节。有疑问欢迎留言探讨
    个人源码地址：https://github.com/FlashLightNing/openjdk-notes
    还有一个openjdk6,7,8,9的地址：https://github.com/dmlloyd/openjdk
    jvm源码阅读笔记[1]：如何触发一次CMS回收
    jvm源码阅读笔记[2]：你不知道的晋升阈值TenuringThreshold详解
    jvm源码阅读笔记[3]：从内存分配到触发GC的细节
    jvm源码阅读笔记[4]：从GC说到vm operation
    jvm源码阅读笔记[5]：内存分配失败触发的GC究竟对内存做了什么？