一個導致JVM實體記憶體消耗大的Bug

概述

最近我們公司在幫一個客戶查一個JVM的問題(JDK1.8.0_191-b12)，發現一個系統老是被OS Kill掉，是記憶體洩露導致的。在查的過程中，陰差陽錯地發現了JVM另外的一個Bug。這個Bug可能會導致大量實體記憶體被使用，我們已經反饋給了社群，並得到快速反饋，預計在OpenJDK8最新版中釋出(JDK11中也存在這個問題)。 

PS：使用者的那個問題最終也解決了，定位下來算是C2的一個設計缺陷導致大量記憶體被使用，安全性上沒有得到保障。

找出消耗大記憶體的執行緒

接下來主要分享下這個BUG的發現過程，先要客戶實時跟蹤程式的情況，當記憶體使用明顯上升的時候，透過/proc/<pid>/smaps，看到了不少64MB的記憶體分配，Rss也基本消耗完了。

7fd690000000-7fd693f23000 rw-p 00000000 00:00 0 Size:              64652 kBRss:               64652 kBPss:               64652 kBShared_Clean:          0 kBShared_Dirty:          0 kBPrivate_Clean:         0 kBPrivate_Dirty:     64652 kBReferenced:        64652 kBAnonymous:         64652 kBAnonHugePages:         0 kBSwap:                  0 kBKernelPageSize:        4 kBMMUPageSize:           4 kBLocked:                0 kBVmFlags: rd wr mr mw me nr sd 7fd693f23000-7fd694000000 ---p 00000000 00:00 0 Size:                884 kBRss:                   0 kBPss:                   0 kBShared_Clean:          0 kBShared_Dirty:          0 kBPrivate_Clean:         0 kBPrivate_Dirty:         0 kBReferenced:            0 kBAnonymous:             0 kBAnonHugePages:         0 kBSwap:                  0 kBKernelPageSize:        4 kBMMUPageSize:           4 kBLocked:                0 kBVmFlags: mr mw me nr sd

再透過strace命令跟蹤了下系統呼叫，再回到上面的虛擬地址，我們找到了相關的mmap系統呼叫

[pid    71] 13:34:41.982589 mmap(0x7fd690000000, 67108864, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x7fd690000000 <0.000107>

執行mmap的執行緒是71號執行緒，接著透過jstack把執行緒dump出來，找到了對應的執行緒其實是C2 CompilerThread0

"C2 CompilerThread0" #39 daemon prio=9 os_prio=0 tid=0x00007fd8acebb000 nid=0x47 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

最後再grep了一下strace的輸出，果然看到這個執行緒在大量的進行記憶體分配，總共有2G多。

經典的64M問題

對於64M的問題，是一個非常經典的問題，在JVM中並沒有這種大量分配64M大小的邏輯，因此可以排除JVM特定意義的分配。這其實是glibc裡針對malloc函式分配記憶體的一種機制，glibc從2.10開始提供的一種機制，為了分配記憶體更加高效，glibc提供了arena的機制，預設情況下在64位下每一個arena的大小是64M，下面是64M的計算邏輯，其中sizeof(long)為8

define DEFAULT_MMAP_THRESHOLD_MAX (4 * 1024 * 1024 * sizeof(long))define HEAP_MAX_SIZE (2 * DEFAULT_MMAP_THRESHOLD_MAX)
p2 = (char *) MMAP (aligned_heap_area, HEAP_MAX_SIZE, PROT_NONE,
                          MAP_NORESERVE);

一個程式最多能分配的arena個數在64位下是8 * core，32位下是2 * core個

#define NARENAS_FROM_NCORES(n) ((n) * (sizeof (long) == 4 ? 2 : 8))
 {              int n = __get_nprocs ();              if (n >= 1)
                narenas_limit = NARENAS_FROM_NCORES (n);              else
                /* We have no information about the system.  Assume two
                   cores.  */
                narenas_limit = NARENAS_FROM_NCORES (2);
            }

這種分配機制的好處，主要是應對多執行緒的環境，為每個核留有幾個64M的快取塊，這樣執行緒在分配記憶體的時候因為沒有鎖而變得更高效，如果達到上限了就會去慢速的main_arena裡分配了。

可以透過設定環境變數MALLOC_ARENA_MAX來設定64M塊的個數，當我們設定為1的時候就會發現這些64M的記憶體塊都沒有了，然後都集中分配到一個大區域了，也就是main_arena，說明這個引數生效了。

無意的發現

再回過來思考為什麼C2執行緒會出現大於2G的記憶體消耗的時候，無意中跟蹤C2這塊程式碼發現瞭如下程式碼可能會導致大量記憶體消耗，這個程式碼的位置是nmethod.cpp的nmethod::metadata_do方法，不過這塊如果真的發生的話，肯定不是看到C2的執行緒大量分配，而是看到VMThread這個執行緒，因為下面這塊程式碼主要是它執行的。

void nmethod::metadata_do(void f(Metadata*)) {
  address low_boundary = verified_entry_point();  if (is_not_entrant()) {
    low_boundary += NativeJump::instruction_size;    // %%% Note:  On SPARC we patch only a 4-byte trap, not a full NativeJump.
    // (See comment above.)
  }
  {    // Visit all immediate references that are embedded in the instruction stream.
    RelocIterator iter(this, low_boundary);    while (iter.next()) {      if (iter.type() == relocInfo::metadata_type ) {
        metadata_Relocation* r = iter.metadata_reloc();        // In this metadata, we must only follow those metadatas directly embedded in
        // the code.  Other metadatas (oop_index>0) are seen as part of
        // the metadata section below.
        assert(1 == (r->metadata_is_immediate()) +
               (r->metadata_addr() >= metadata_begin() && r->metadata_addr() < metadata_end()),
               “metadata must be found in exactly one place”);        if (r->metadata_is_immediate() && r->metadata_value() != NULL) {
          Metadata* md = r->metadata_value();          if (md != _method) f(md);
        }
      } else if (iter.type() == relocInfo::virtual_call_type) {        // Check compiledIC holders associated with this nmethod
        CompiledIC *ic = CompiledIC_at(&iter);        if (ic->is_icholder_call()) {
          CompiledICHolder* cichk = ic->cached_icholder();
          f(cichk->holder_metadata());
          f(cichk->holder_klass());
        } else {
          Metadata* ic_oop = ic->cached_metadata();          if (ic_oop != NULL) {
            f(ic_oop);
          }
        }
      }
    }
  }
inline CompiledIC* CompiledIC_at(RelocIterator* reloc_iter) {
  assert(reloc_iter->type() == relocInfo::virtual_call_type ||
      reloc_iter->type() == relocInfo::opt_virtual_call_type, "wrong reloc. info");
  CompiledIC* c_ic = new CompiledIC(reloc_iter);
  c_ic->verify();  return c_ic;
}

注意上面的CompiledIC *ic = CompiledIC_at(&iter);這段程式碼，因為CompiledIC是一個ResourceObj，這種資源會在c heap裡分配(malloc)，不過他們是和執行緒進行關聯的，假如我們在某處程式碼宣告瞭ResourceMark，那當執行到這裡的時候會標記當前的位置，再接下來執行緒要分配記憶體的時候如果執行緒關聯的記憶體不夠用，就會malloc一塊插進去並被管理起來，否則會實現記憶體的複用。當ResourceMark解構函式執行的時候，會將之前的位置還原，後面這個執行緒如果要分配記憶體又會從這個位置開始複用記憶體塊。注意這裡說的記憶體塊和上面的64M記憶體塊不是一個概念。

因為這段程式碼在while迴圈裡，因此存在非常多次數的重複呼叫，這樣明明在執行完一次之後可以複用記憶體的地方並不能複用，而可能會導致大量的記憶體被不斷分配。表現起來可能就是實體記憶體消耗很大，遠大於Xmx。

這個修復辦法也很簡單，就是在CompiledIC *ic = CompiledIC_at(&iter);前加上ResourceMark rm;即可。

這個問題主要發生的場景是針對頻繁大量做Class Retransform或者Class Redefine的場景。所以如果系統裡有這種agent的時候還是要稍微注意下這個問題。

這個問題發現後我們給社群提了patch，不過後面發現再JDK12中其實已經修復了，但是在之前的版本里的都沒有修復，這個問題提交給社群後，有人很快響應了，並可能在OpenJDK1.8.0-212中被fix。

最後在這裡也簡單提下客戶那邊的那個問題，之所以C2執行緒消耗太大，最主要的原因是存在非常大的方法需要編譯，而這個編譯的過程是需要大量的記憶體消耗的，正因為如此，才會導致記憶體突然暴增，所以給大家一個建議，方法不要寫太大啦，如果這個方法呼叫還很頻繁，那真的會很悲劇的。