主頁 >  其他 > 詳解Native Memory Tracking之追蹤區域分析

詳解Native Memory Tracking之追蹤區域分析

2022-11-19 07:18:38 其他

摘要：本篇圖文將介紹追蹤區域的記憶體型別以及 NMT 無法追蹤的記憶體，

本文分享自華為云社區《【技術剖析】17. Native Memory Tracking 詳解（3）追蹤區域分析(二)》，作者：畢昇小助手，

Compiler

Compiler 就是 JIT 編譯器執行緒在編譯 code 時本身所使用的記憶體，查看 NMT 詳情：

[0x0000ffff93e3acc0] Thread::allocate(unsigned long, bool, MemoryType)+0x348
[0x0000ffff9377a498] CompileBroker::make_compiler_thread(char const*, CompileQueue*, CompilerCounters*, AbstractCompiler*, Thread*)+0x120
[0x0000ffff9377ce98] CompileBroker::init_compiler_threads(int, int)+0x148
[0x0000ffff9377d400] CompileBroker::compilation_init()+0xc8
                             (malloc=37KB type=Thread #12)

跟蹤呼叫鏈路：InitializeJVM ->
Threads::create_vm ->
CompileBroker::compilation_init ->
CompileBroker::init_compiler_threads ->
CompileBroker::make_compiler_thread

發現最后 make_compiler_thread 的執行緒的個數是在 compilation_init() 中計算的：

# hotspot/src/share/vm/compiler/CompileBroker.cpp
void CompileBroker::compilation_init() {
  ......
 // No need to initialize compilation system if we do not use it.
 if (!UseCompiler) {
 return;
  }
#ifndef SHARK
 // Set the interface to the current compiler(s).
  int c1_count = CompilationPolicy::policy()->compiler_count(CompLevel_simple);
  int c2_count = CompilationPolicy::policy()->compiler_count(CompLevel_full_optimization);
  ......
 // Start the CompilerThreads
 init_compiler_threads(c1_count, c2_count);
  ......
}

追溯 c1_count、c2_count 的計算邏輯，首先在 JVM 初始化的時候（Threads::create_vm -> init_globals -> compilationPolicy_init）要設定編譯的策略 CompilationPolicy：

# hotspot/src/share/vm/runtime/arguments.cpp
void Arguments::set_tiered_flags() {
 // With tiered, set default policy to AdvancedThresholdPolicy, which is 3.
 if (FLAG_IS_DEFAULT(CompilationPolicyChoice)) {
    FLAG_SET_DEFAULT(CompilationPolicyChoice, 3);
  }
  ......
}
# hotspot/src/share/vm/runtime/compilationPolicy.cpp
// Determine compilation policy based on command line argument
void compilationPolicy_init() {
 CompilationPolicy::set_in_vm_startup(DelayCompilationDuringStartup);
 switch(CompilationPolicyChoice) {
  ......
 case 3:
#ifdef TIERED
 CompilationPolicy::set_policy(new AdvancedThresholdPolicy());
#else
 Unimplemented();
#endif
 break;
  ......
 CompilationPolicy::policy()->initialize();
}

此時我們默認開啟了分層編譯，所以 CompilationPolicyChoice 為 3 ，編譯策略選用的是 AdvancedThresholdPolicy，查看相關原始碼（compilationPolicy_init -> AdvancedThresholdPolicy::initialize）：

# hotspot/src/share/vm/runtime/advancedThresholdPolicy.cpp
void AdvancedThresholdPolicy::initialize() {
 // Turn on ergonomic compiler count selection
 if (FLAG_IS_DEFAULT(CICompilerCountPerCPU) && FLAG_IS_DEFAULT(CICompilerCount)) {
    FLAG_SET_DEFAULT(CICompilerCountPerCPU, true);
  }
 int count = CICompilerCount;
 if (CICompilerCountPerCPU) {
 // Simple log n seems to grow too slowly for tiered, try something faster: log n * log log n
 int log_cpu = log2_int(os::active_processor_count());
 int loglog_cpu = log2_int(MAX2(log_cpu, 1));
    count = MAX2(log_cpu * loglog_cpu, 1) * 3 / 2;
  }
  set_c1_count(MAX2(count / 3, 1));
  set_c2_count(MAX2(count - c1_count(), 1));
  ......
}

我們可以發現，在未手動設定 -XX:CICompilerCountPerCPU 和 -XX:CICompilerCount 這兩個引數的時候，JVM 會啟動 CICompilerCountPerCPU ，啟動編譯執行緒的數目會根據 CPU 數重新計算而不再使用默認的 CICompilerCount 的值（3），計算公式通常情況下為 log n * log log n * 1.5（log 以 2 為底），此時筆者使用的機器有 64 個 CPU，經過計算得出編譯執行緒的數目為 18，計算出編譯執行緒的總數目之后，再按 1:2 的比例分別分配給 C1、C2，即我們上文所求的 c1_count、c2_count，

使用 jinfo -flag CICompilerCount 來驗證此時 JVM 行程的編譯執行緒數目：

jinfo -flag CICompilerCount 
-XX:CICompilerCount=18

所以我們可以通過顯式的設定 -XX:CICompilerCount 來控制 JVM 開啟編譯執行緒的數目，從而限制 Compiler 部分所使用的記憶體（當然這部分記憶體比較小），

我們還可以通過 -XX:-TieredCompilation 關閉分層編譯來降低記憶體使用，當然是否關閉分層編譯取決于實際的業務需求，節省的這點記憶體實在微乎其微，

編譯執行緒也是執行緒，所以我們還可以通過 -XX:VMThreadStackSize 設定一個更小的值來節省此部分記憶體，但是削減虛擬機執行緒的堆疊大小是危險的操作，并不建議去因為此設定這個引數，

Internal

Internal 包含命令列決議器使用的記憶體、JVMTI、PerfData 以及 Unsafe 分配的記憶體等等，

其中命令列解釋器就是在初始化創建虛擬機時對 JVM 的命令列引數加以決議并執行相應的操作，如對引數 -XX:NativeMemoryTracking=detail 進行決議，

JVMTI（JVM Tool Interface）是開發和監視 JVM 所使用的編程介面，它提供了一些方法去檢查 JVM 狀態和控制 JVM 的運行，詳情可以查看 JVMTI官方檔案 [1]，

PerfData 是 JVM 中用來記錄一些指標資料的檔案，如果開啟 -XX:+UsePerfData（默認開啟），JVM 會通過 mmap 的方式（即使用上文中提到的 os::reserve_memory 和 os::commit_memory）去映射到 {tmpdir}/hsperfdata_/pid 檔案中，jstat 通過讀取 PerfData 中的資料來展示 JVM 行程中的各種指標資訊.

需要注意的是， {tmpdir}/hsperfdata_/pid 與{tmpdir}/.java_pid 并不是一個東西，后者是在 Attach 機制中用來通訊的，類似一種 Unix Domain Socket 的思想，不過真正的 Unix Domain Socket（JEP380 [2]）在 JDK16 中才支持，

我們在操作 nio 時經常使用 ByteBuffer ，其中 ByteBuffer.allocateDirect / DirectByteBuffer 會通過 unsafe.allocateMemory 的方式來 malloc 分配 naive memory，雖然 DirectByteBuffer 本身還是存放于 Heap 堆中，但是它對應的 address 映射的卻是分配在堆外記憶體的 native memory，NMT 會將 Unsafe_AllocateMemory 方式分配的記憶體記錄在 Internal 之中（jstat 也是通過 ByteBuffer 的方式來使用 PerfData），

需要注意的是，Unsafe_AllocateMemory 分配的記憶體在 JDK11之前，在 NMT 中都屬于 Internal，但是在 JDK11 之后被 NMT 歸屬到 Other 中，例如相同 ByteBuffer.allocateDirect 在 JDK11 中進行追蹤：[0x0000ffff8c0b4a60] Unsafe_AllocateMemory0+0x60[0x0000ffff6b822fbc] (malloc=393218KB type=Other #3)

簡單查看下相關原始碼：

# ByteBuffer.java
 public static ByteBuffer allocateDirect(int capacity) {
 return new DirectByteBuffer(capacity);
    }
# DirectByteBuffer.java
 DirectByteBuffer(int cap) {                   // package-private
        ......
 long base = 0;
 try {
 base = unsafe.allocateMemory(size);
        }
       ......
# Unsafe.java
 public native long allocateMemory(long bytes);
# hotspot/src/share/vm/prims/unsafe.cpp
UNSAFE_ENTRY(jlong, Unsafe_AllocateMemory(JNIEnv *env, jobject unsafe, jlong size))
 UnsafeWrapper("Unsafe_AllocateMemory");
 size_t sz = (size_t)size;
  ......
 sz = round_to(sz, HeapWordSize);
 void* x = os::malloc(sz, mtInternal);
  ......
UNSAFE_END

一般情況下，命令列解釋器、JVMTI等方式不會申請太大的記憶體，我們需要注意的是通過 Unsafe_AllocateMemory 方式申請的堆外記憶體（如業務使用了 Netty ），可以通過一個簡單的示例來進行驗證，這個示例的 JVM 啟動引數為：-Xmx1G -Xms1G -XX:+UseG1GC -XX:MaxMetaspaceSize=256M -XX:ReservedCodeCacheSize=256M -XX:NativeMemoryTracking=detail（去除了 -XX:MaxDirectMemorySize=256M 的限制）：

import java.nio.ByteBuffer;
public class ByteBufferTest {
 private static int _1M = 1024 * 1024;
 private static ByteBuffer allocateBuffer_1 = ByteBuffer.allocateDirect(128 * _1M);
 private static ByteBuffer allocateBuffer_2 = ByteBuffer.allocateDirect(256 * _1M);
 public static void main(String[] args) throws Exception {
        System.out.println("MaxDirect memory: " + sun.misc.VM.maxDirectMemory() + " bytes");
        System.out.println("Direct allocation: " + (allocateBuffer_1.capacity() + allocateBuffer_2.capacity()) + " bytes");
        System.out.println("Native memory used: " + sun.misc.SharedSecrets.getJavaNioAccess().getDirectBufferPool().getMemoryUsed() + " bytes");
 Thread.sleep(6000000);
    }
}

查看輸出：

MaxDirect memory: 1073741824 bytes
Direct allocation: 402653184 bytes
Native memory used: 402653184 bytes

查看 NMT 詳情：

-                  Internal (reserved=405202KB, committed=405202KB)
                            (malloc=405170KB #3605) 
                            (mmap: reserved=32KB, committed=32KB) 
                   ......
                   [0x0000ffffbb599190] Unsafe_AllocateMemory+0x1c0
                   [0x0000ffffa40157a8]
                             (malloc=393216KB type=Internal #2)
                   ......
                   [0x0000ffffbb04b3f8] GenericGrowableArray::raw_allocate(int)+0x188
                   [0x0000ffffbb4339d8] PerfDataManager::add_item(PerfData*, bool) [clone .constprop.16]+0x108
                   [0x0000ffffbb434118] PerfDataManager::create_string_variable(CounterNS, char const*, int, char const*, Thread*)+0x178
                   [0x0000ffffbae9d400] CompilerCounters::CompilerCounters(char const*, int, Thread*) [clone .part.78]+0xb0
                             (malloc=3KB type=Internal #1)
                   ......

可以發現，我們在代碼中使用 ByteBuffer.allocateDirect（內部也是使用 new DirectByteBuffer(capacity)）的方式，即 Unsafe_AllocateMemory 申請的堆外記憶體被 NMT 以 Internal 的方式記錄了下來：（128 M + 256 M）= 384 M = 393216 KB = 402653184 Bytes，

當然我們可以使用引數 -XX:MaxDirectMemorySize 來限制 Direct Buffer 申請的最大記憶體，

Symbol

Symbol 為 JVM 中的符號表所使用的記憶體，HotSpot中符號表主要有兩種：SymbolTable 與 StringTable，

大家都知道 Java 的類在編譯之后會生成 Constant pool 常量池，常量池中會有很多的字串常量，HotSpot 出于節省記憶體的考慮，往往會將這些字串常量作為一個 Symbol 物件存入一個 HashTable 的表結構中即 SymbolTable，如果該字串可以在 SymbolTable 中 lookup（SymbolTable::lookup）到，那么就會重用該字串，如果找不到才會創建新的 Symbol（SymbolTable::new_symbol），

當然除了 SymbolTable，還有它的雙胞胎兄弟 StringTable（StringTable 結構與 SymbolTable 基本是一致的，都是 HashTable 的結構），即我們常說的字串常量池，平時做業務開發和 StringTable 打交道會更多一些，HotSpot 也是基于節省記憶體的考慮為我們提供了 StringTable，我們可以通過 String.intern 的方式將字串放入 StringTable 中來重用字串，

撰寫一個簡單的示例：

public class StringTableTest {
 public static void main(String[] args) throws Exception {
 while (true){
            String str = new String("StringTestData_" + System.currentTimeMillis());
 str.intern();
        }
    }
}

啟動程式后我們可以使用 jcmd VM.native_memory baseline 來創建一個基線方便對比，稍作等待后再使用 jcmd VM.native_memory summary.diff/detail.diff 與創建的基線作對比，對比后我們可以發現：

Total: reserved=2831553KB +20095KB, committed=1515457KB +20095KB
......
-                    Symbol (reserved=18991KB +17144KB, committed=18991KB +17144KB)
                            (malloc=18504KB +17144KB #2307 +2143)
                            (arena=488KB #1)
......
[0x0000ffffa2aef4a8] BasicHashtable<(MemoryType)9>::new_entry(unsigned int)+0x1a0
[0x0000ffffa2aef558] Hashtable::new_entry(unsigned int, oopDesc*)+0x28
[0x0000ffffa2fbff78] StringTable::basic_add(int, Handle, unsigned short*, int, unsigned int, Thread*)+0xe0
[0x0000ffffa2fc0548] StringTable::intern(Handle, unsigned short*, int, Thread*)+0x1a0
                             (malloc=17592KB type=Symbol +17144KB #2199 +2143)
......

JVM 行程這段時間記憶體一共增長了 20095KB，其中絕大部分都是 Symbol 申請的記憶體（17144KB），查看具體的申請資訊正是 StringTable::intern 在不斷的申請記憶體，

如果我們的程式錯誤的使用 String.intern() 或者 JDK intern 相關 BUG 導致了記憶體例外，可以通過這種方式輕松協助定位出來，

需要注意的是，虛擬機提供的引數 -XX:StringTableSize 并不是來限制 StringTable 最大申請的記憶體大小的，而是用來限制 StringTable 的表的長度的，我們加上 -XX:StringTableSize=10M 來重新啟動 JVM 行程，一段時間后查看 NMT 追蹤情況：

-                    Symbol (reserved=100859KB +17416KB, committed=100859KB +17416KB)
                            (malloc=100371KB +17416KB #2359 +2177)
                            (arena=488KB #1)
......
[0x0000ffffa30c14a8] BasicHashtable<(MemoryType)9>::new_entry(unsigned int)+0x1a0
[0x0000ffffa30c1558] Hashtable::new_entry(unsigned int, oopDesc*)+0x28
[0x0000ffffa3591f78] StringTable::basic_add(int, Handle, unsigned short*, int, unsigned int, Thread*)+0xe0
[0x0000ffffa3592548] StringTable::intern(Handle, unsigned short*, int, Thread*)+0x1a0
                             (malloc=18008KB type=Symbol +17416KB #2251 +2177)

可以發現 StringTable 的大小是超過 10M 的，查看該引數的作用：

# hotsopt/src/share/vm/classfile/symnolTable.hpp
 StringTable() : RehashableHashtable((int)StringTableSize,
 sizeof (HashtableEntry)) {}
 StringTable(HashtableBucket* t, int number_of_entries)
    : RehashableHashtable((int)StringTableSize, sizeof (HashtableEntry), t,
 number_of_entries) {}

因為 StringTable 在 HotSpot 中是以 HashTable 的形式存盤的，所以 -XX:StringTableSize 引數設定的其實是 HashTable 的長度，如果該值設定的過小的話，即使 HashTable 進行 rehash，hash 沖突也會十分頻繁，會造成性能劣化并有可能導致進入 SafePoint 的時間增長，如果發生這種情況，可以調大該值，

  • -XX:StringTableSize在 32 位系統默認為 1009、64 位默認為 60013 ：const int defaultStringTableSize = NOT_LP64(1009) LP64_ONLY(60013);，
  • G1中可以使用 -XX:+UseStringDeduplication引數來開啟字串自動去重功能（默認關閉），并使用 -XX:StringDeduplicationAgeThreshold來控制字串參與去重的 GC 年齡閾值，
  • 與 -XX:StringTableSize同理，我們可以通過 -XX:SymbolTableSize來控制SymbolTable表的長度，

如果我們使用的是 JDK11 之后的 NMT，我們可以直接通過命令 jcmd VM.stringtable 與 jcmd VM.symboltable 來查看兩者的使用情況：

StringTable statistics:
Number of buckets       : 16777216 = 134217728 bytes, each 8
Number of entries       : 39703 =    635248 bytes, each 16
Number of literals      : 39703 =   2849304 bytes, avg  71.765
Total footprsize_t   :           = 137702280 bytes
Average bucket size     : 0.002
Variance of bucket size : 0.002
Std. dev. of bucket size:     0.049
Maximum bucket size     : 2
SymbolTable statistics:
Number of buckets       : 20011 =    160088 bytes, each 8
Number of entries       : 20133 =    483192 bytes, each 24
Number of literals      : 20133 =    753832 bytes, avg  37.443
Total footprint         :           =   1397112 bytes
Average bucket size     : 1.006
Variance of bucket size : 1.013
Std. dev. of bucket size:     1.006
Maximum bucket size     : 9

Native Memory Tracking

Native Memory Tracking 使用的記憶體就是 JVM 行程開啟 NMT 功能后，NMT 功能自身所申請的記憶體，

查看原始碼會發現，JVM 會在 MemTracker::init() 初始化的時候，使用 tracking_level() -> init_tracking_level() 獲取我們設定的 tracking_level 追蹤等級（如：summary、detail），然后將獲取到的 level 分別傳入 MallocTracker::initialize(level) 與 VirtualMemoryTracker::initialize(level) 進行判斷，只有 level >= summary 的情況下，虛擬機才會分配 NMT 自身所用到的記憶體，如：VirtualMemoryTracker、MallocMemorySummary、MallocSiteTable（detail 時才會創建） 等來記錄 NMT 追蹤的各種資料，

# /hotspot/src/share/vm/services/memTracker.cpp
void MemTracker::init() {
 NMT_TrackingLevel level = tracking_level();
  ......
}
# /hotspot/src/share/vm/services/memTracker.hpp
static inline NMT_TrackingLevel tracking_level() {
 if (_tracking_level == NMT_unknown) {
 // No fencing is needed here, since JVM is in single-threaded
 // mode.
      _tracking_level = init_tracking_level();
      _cmdline_tracking_level = _tracking_level;
    }
 return _tracking_level;
  }
# /hotspot/src/share/vm/services/memTracker.cpp
NMT_TrackingLevel MemTracker::init_tracking_level() {
 NMT_TrackingLevel level = NMT_off;
  ......
 if (os::getenv(buf, nmt_option, sizeof(nmt_option))) {
 if (strcmp(nmt_option, "summary") == 0) {
      level = NMT_summary;
    } else if (strcmp(nmt_option, "detail") == 0) {
#if PLATFORM_NATIVE_STACK_WALKING_SUPPORTED
      level = NMT_detail;
#else
      level = NMT_summary;
#endif // PLATFORM_NATIVE_STACK_WALKING_SUPPORTED
    } 
   ......
  }
  ......
 if (!MallocTracker::initialize(level) ||
 !VirtualMemoryTracker::initialize(level)) {
    level = NMT_off;
  }
 return level;
}
# /hotspot/src/share/vm/services/memTracker.cpp
bool MallocTracker::initialize(NMT_TrackingLevel level) {
 if (level >= NMT_summary) {
 MallocMemorySummary::initialize();
  }
 if (level == NMT_detail) {
 return MallocSiteTable::initialize();
  }
 return true;
}
void MallocMemorySummary::initialize() {
  assert(sizeof(_snapshot) >= sizeof(MallocMemorySnapshot), "Sanity Check");
 // Uses placement new operator to initialize static area.
 ::new ((void*)_snapshot)MallocMemorySnapshot();
}
# 
bool VirtualMemoryTracker::initialize(NMT_TrackingLevel level) {
 if (level >= NMT_summary) {
 VirtualMemorySummary::initialize();
  }
 return true;
}

我們執行的 jcmd VM.native_memory summary/detail 命令，就會使用 NMTDCmd::report 方法來根據等級的不同獲取不同的資料：

  • summary 時使用 MemSummaryReporter::report() 獲取 VirtualMemoryTracker、MallocMemorySummary 等儲存的資料；
  • detail 時使用 MemDetailReporter::report() 獲取 VirtualMemoryTracker、MallocMemorySummary、MallocSiteTable 等儲存的資料，
# hotspot/src/share/vm/services/nmtDCmd.cpp
void NMTDCmd::execute(DCmdSource source, TRAPS) {
  ......
 if (_summary.value()) {
 report(true, scale_unit);
  } else if (_detail.value()) {
 if (!check_detail_tracking_level(output())) {
 return;
    }
 report(false, scale_unit);
  }
  ......
}
void NMTDCmd::report(bool summaryOnly, size_t scale_unit) {
 MemBaseline baseline;
 if (baseline.baseline(summaryOnly)) {
 if (summaryOnly) {
 MemSummaryReporter rpt(baseline, output(), scale_unit);
 rpt.report();
    } else {
 MemDetailReporter rpt(baseline, output(), scale_unit);
 rpt.report();
    }
  }
}

一般 NMT 自身占用的記憶體是比較小的，不需要太過關心，

Arena Chunk

Arena 是 JVM 分配的一些 Chunk（記憶體塊），當退出作用域或離開代碼區域時，記憶體將從這些 Chunk 中釋放出來，然后這些 Chunk 就可以在其他子系統中重用. 需要注意的是，此時統計的 Arena 與 Chunk ，是 HotSpot 自己定義的 Arena、Chunk，而不是 Glibc 中相關的 Arena 與 Chunk 的概念，

我們會發現 NMT 詳情中會有很多關于 Arena Chunk 的分配資訊都是：

[0x0000ffff935906e0] ChunkPool::allocate(unsigned long, AllocFailStrategy::AllocFailEnum)+0x158
[0x0000ffff9358ec14] Arena::Arena(MemoryType, unsigned long)+0x18c
......

JVM 中通過 ChunkPool 來管理重用這些 Chunk，比如我們在創建執行緒時：

# /hotspot/src/share/vm/runtime/thread.cpp
Thread::Thread() {
  ......
 set_resource_area(new (mtThread)ResourceArea());
  ......
 set_handle_area(new (mtThread) HandleArea(NULL));
  ......

其中 ResourceArea 屬于給執行緒分配的一個資源空間，一般 ResourceObj 都存放于此（如 C1/C2 優化時需要訪問的運行時資訊）；HandleArea 則用來存放執行緒所持有的句柄（handle），使用句柄來關聯使用的物件，這兩者都會去申請 Arena，而 Arena 則會通過 ChunkPool::allocate 來申請一個新的 Chunk 記憶體塊，除此之外，JVM 行程用到 Arena 的地方還有非常多，比如 JMX、OopMap 等等一些相關的操作都會用到 ChunkPool，

眼尖的讀者可能會注意到上文中提到，通常情況下會通過 ChunkPool::allocate 的方式來申請 Chunk 記憶體塊，是的，其實除了 ChunkPool::allocate 的方式， JVM 中還存在另外一種申請 Arena Chunk 的方式，即直接借助 Glibc 的 malloc 來申請記憶體，JVM 為我們提供了相關的控制引數 UseMallocOnly：

develop(bool, UseMallocOnly, false,                                       \
 "Use only malloc/free for allocation (no resource area/arena)")

我們可以發現這個引數是一個 develop 的引數，一般情況下我們是使用不到的，因為 VM option 'UseMallocOnly' is develop and is available only in debug version of VM，即我們只能在 debug 版本的 JVM 中才能開啟該引數，

這里有的讀者可能會有一個疑問，即是不是可以通過使用引數 -XX:+IgnoreUnrecognizedVMOptions（該引數開啟之后可以允許 JVM 使用一些在 release 版本中不被允許使用的引數）的方式，在正常 release 版本的 JVM 中使用 UseMallocOnly 引數，很遺憾雖然我們可以通過這種方式開啟 UseMallocOnly，但是實際上 UseMallocOnly 卻不會生效，因為在原始碼中其邏輯如下：

# hotspot/src/share/vm/memory/allocation.hpp
void* Amalloc(size_t x, AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) {
    assert(is_power_of_2(ARENA_AMALLOC_ALIGNMENT) , "should be a power of 2");
    x = ARENA_ALIGN(x);
 //debug 版本限制
 debug_only(if (UseMallocOnly) return malloc(x);)
 if (!check_for_overflow(x, "Arena::Amalloc", alloc_failmode))
 return NULL;
    NOT_PRODUCT(inc_bytes_allocated(x);)
 if (_hwm + x > _max) {
 return grow(x, alloc_failmode);
    } else {
 char *old = _hwm;
      _hwm += x;
 return old;
    }
  }

可以發現，即使我們成功開啟了 UseMallocOnly，也只有在 debug 版本（debug_only）的 JVM 中才能使用 malloc 的方式分配記憶體，

我們可以對比下，使用正常版本（release）的 JVM 添加 -XX:+IgnoreUnrecognizedVMOptions -XX:+UseMallocOnly 啟動引數的 NMT 相關日志與使用 debug（fastdebug/slowdebug）版本的 JVM 添加 -XX:+UseMallocOnly 啟動引數的 NMT 相關日志：

# 正常 JVM ，啟動引數添加：-XX:+IgnoreUnrecognizedVMOptions -XX:+UseMallocOnly
......
[0x0000ffffb7d16968] ChunkPool::allocate(unsigned long, AllocFailStrategy::AllocFailEnum)+0x158
[0x0000ffffb7d15f58] Arena::grow(unsigned long, AllocFailStrategy::AllocFailEnum)+0x50
[0x0000ffffb7fc4888] Dict::Dict(int (*)(void const*, void const*), int (*)(void const*), Arena*, int)+0x138
[0x0000ffffb85e5968] Type::Initialize_shared(Compile*)+0xb0
                             (malloc=32KB type=Arena Chunk #1)
......                             
 

# debug版本 JVM ，啟動引數添加：-XX:+UseMallocOnly
......
[0x0000ffff8dfae910] Arena::malloc(unsigned long)+0x74
[0x0000ffff8e2cb3b8] Arena::Amalloc_4(unsigned long, AllocFailStrategy::AllocFailEnum)+0x70
[0x0000ffff8e2c9d5c] Dict::Dict(int (*)(void const*, void const*), int (*)(void const*), Arena*, int)+0x19c
[0x0000ffff8e97c3d0] Type::Initialize_shared(Compile*)+0x9c
                             (malloc=5KB type=Arena Chunk #1)
......

我們可以清晰地觀察到呼叫鏈的不同，即前者還是使用 ChunkPool::allocate 的方式來申請記憶體，而后者則使用 Arena::malloc 的方式來申請記憶體，查看 Arena::malloc 代碼：

# hotspot/src/share/vm/memory/allocation.cpp
void* Arena::malloc(size_t size) {
 assert(UseMallocOnly, "shouldn't call");
 // use malloc, but save pointer in res. area for later freeing
 char** save = (char**)internal_malloc_4(sizeof(char*));
 return (*save = (char*)os::malloc(size, mtChunk));
}

可以發現代碼中通過 os::malloc 的方式來分配記憶體，同理釋放記憶體時直接通過 os::free 即可，如 UseMallocOnly 中釋放記憶體的相關代碼：

# hotspot/src/share/vm/memory/allocation.cpp
// debugging code
inline void Arena::free_all(char** start, char** end) {
 for (char** p = start; p < end; p++) if (*p) os::free(*p);
}

雖然 JVM 為我們提供了兩種方式來管理 Arena Chunk 的記憶體：

  1. 通過 ChunkPool 池化交由 JVM 自己管理；
  2. 直接通過 Glibc 的 malloc/free 來進行管理，

但是通常意義下我們只會用到第一種方式，并且一般 ChunkPool 管理的物件都比較小，整體來看 Arena Chunk 這塊記憶體的使用不會很多，

Unknown

Unknown 則是下面幾種情況

  • 當記憶體類別無法確定時；
  • 當 Arena 用作堆疊或值物件時；
  • 當型別資訊尚未到達時，

NMT 無法追蹤的記憶體

需要注意的是，NMT 只能跟蹤 JVM 代碼的記憶體分配情況，對于非 JVM 的記憶體分配是無法追蹤到的，

  • 使用 JNI 呼叫的一些第三方 native code 申請的記憶體，比如使用 System.Loadlibrary 加載的一些庫，
  • 標準的 Java Class Library，典型的，如檔案流等相關操作（如：Files.list、ZipInputStream 和 DirectoryStream 等），

可以使用作業系統的記憶體工具等協助排查，或者使用 LD_PRELOAD malloc 函式的 hook/jemalloc/google-perftools(tcmalloc) 來代替 Glibc 的 malloc，協助追蹤記憶體的分配，

由于篇幅有限，將在下篇文章給大家分享“使用 NMT 協助排查記憶體問題的案例”，敬請期待！

參考

 

  1. https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html
  2. https://openjdk.org/jeps/380

歡迎加入Compiler SIG交流群與大家共同交流學習編譯技術相關內容，掃碼添加小助手微信邀請你進入Compiler SIG交流群，

 

點擊關注，第一時間了解華為云新鮮技術~

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/536117.html

標籤：其他

上一篇：淺談深度學習中的概率

下一篇：資料結構基礎—二叉樹的非遞回遍歷和基本操作

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C＃(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 網閘典型架構簡述

    網閘架構一般分為兩種：三主機的三系統架構網閘和雙主機的2+1架構網閘。 三主機架構分別為內端機、外端機和仲裁機。三機無論從軟體和硬體上均各自獨立。首先從硬體上來看，三機都用各自獨立的主板、記憶體及存盤設備。從軟體上來看，三機有各自獨立的作業系統。這樣能達到完全的三機獨立。對于“2+1”系統，“2”分為 ......

    uj5u.com 2020-09-10 02:00:44 more
  • 如何從xshell上傳檔案到centos linux虛擬機里

    如何從xshell上傳檔案到centos linux虛擬機里及：虛擬機CentOs下執行 yum -y install lrzsz命令，出現錯誤：鏡像無法找到軟體包 前言 一、安裝lrzsz步驟 二、上傳檔案 三、遇到的問題及解決方案 總結 前言 提示：其實很簡單，往虛擬機上安裝一個上傳檔案的工具 ......

    uj5u.com 2020-09-10 02:00:47 more
  • 一、SQLMAP入門

    一、SQLMAP入門 1、判斷是否存在注入 sqlmap.py -u 網址/id=1 id=1不可缺少。當注入點后面的引數大于兩個時。需要加雙引號， sqlmap.py -u "網址/id=1&uid=1" 2、判斷文本中的請求是否存在注入 從文本中加載http請求，SQLMAP可以從一個文本檔案中 ......

    uj5u.com 2020-09-10 02:00:50 more
  • Metasploit 簡單使用教程

    metasploit 簡單使用教程 浩先生， 2020-08-28 16:18:25 分類專欄： kail 網路安全 linux 文章標簽： linux資訊安全 編輯 著作權 metasploit 使用教程 前言 一、Metasploit是什么？ 二、準備作業 三、具體步驟 前言 Msfconsole ......

    uj5u.com 2020-09-10 02:00:53 more
  • 游戲逆向之驅動層與用戶層通訊

    驅動層代碼： #pragma once #include <ntifs.h> #define add_code CTL_CODE(FILE_DEVICE_UNKNOWN,0x800,METHOD_BUFFERED,FILE_ANY_ACCESS) /* 更多游戲逆向視頻www.yxfzedu.com ......

    uj5u.com 2020-09-10 02:00:56 more
  • 北斗電力時鐘（北斗授時服務器）讓網路資料更精準

    北斗電力時鐘（北斗授時服務器）讓網路資料更精準 北斗電力時鐘（北斗授時服務器）讓網路資料更精準 京準電子科技官微——ahjzsz 近幾年，資訊技術的得了快速發展，互聯網在逐漸普及，其在人們生活和生產中都得到了廣泛應用，并且取得了不錯的應用效果。計算機網路資訊在電力系統中的應用，一方面使電力系統的運行 ......

    uj5u.com 2020-09-10 02:01:03 more
  • 【CTF】CTFHub 技能樹 彩蛋 writeup

    ?碎碎念 CTFHub：https://www.ctfhub.com/ 筆者入門CTF時時剛開始刷的是bugku的舊平臺，后來才有了CTFHub。 感覺不論是網頁UI設計，還是題目質量，賽事跟蹤，工具軟體都做得很不錯。 而且因為獨到的金幣制度的確讓人有一種想去刷題賺金幣的感覺。 個人還是非常喜歡這個 ......

    uj5u.com 2020-09-10 02:04:05 more
  • 02windows基礎操作

    我學到了一下幾點 Windows系統目錄結構與滲透的作用 常見Windows的服務詳解 Windows埠詳解 常用的Windows注冊表詳解 hacker DOS命令詳解（net user / type /md /rd/ dir /cd /net use copy、批處理 等） 利用dos命令制作 ......

    uj5u.com 2020-09-10 02:04:18 more
  • 03.Linux基礎操作

    我學到了以下幾點 01Linux系統介紹02系統安裝，密碼啊破解03Linux常用命令04LAMP 01LINUX windows： win03 8 12 16 19 配置不繁瑣 Linux：redhat,centos(紅帽社區版)，Ubuntu server,suse unix:金融機構，證券，銀 ......

    uj5u.com 2020-09-10 02:04:30 more
  • 05HTML

    01HTML介紹 02頭部標簽講解03基礎標簽講解04表單標簽講解 HTML前段語言 js1.了解代碼2.根據代碼 懂得挖掘漏洞 （POST注入/XSS漏洞上傳）3.黑帽seo 白帽seo 客戶網站被黑帽植入劫持代碼如何處理4.熟悉html表單 <html><head><title>TDK標題，描述 ......

    uj5u.com 2020-09-10 02:04:36 more
最新发布
  • 2023年最新微信小程式抓包教程

    01 開門見山 隔一個月發一篇文章，不過分。 首先回顧一下《微信系結手機號資料庫被脫庫事件》，我也是第一時間得知了這個訊息，然后跟蹤了整件事情的經過。下面是這起事件的相關截圖以及近日流出的一萬條資料樣本： 個人認為這件事也沒什么，還不如關注一下之前45億快遞資料查詢渠道疑似在近日復活的訊息。 訊息是 ......

    uj5u.com 2023-04-20 08:48:24 more
  • web3 產品介紹：metamask 錢包 使用最多的瀏覽器插件錢包

    Metamask錢包是一種基于區塊鏈技術的數字貨幣錢包，它允許用戶在安全、便捷的環境下管理自己的加密資產。Metamask錢包是以太坊生態系統中最流行的錢包之一，它具有易于使用、安全性高和功能強大等優點。 本文將詳細介紹Metamask錢包的功能和使用方法。 一、 Metamask錢包的功能 數字資 ......

    uj5u.com 2023-04-20 08:47:46 more
  • vulnhub_Earth

    前言 靶機地址->>>vulnhub_Earth 攻擊機ip：192.168.20.121 靶機ip：192.168.20.122 參考文章 https://www.cnblogs.com/Jing-X/archive/2022/04/03/16097695.html https://www.cnb ......

    uj5u.com 2023-04-20 07:46:20 more
  • 從4k到42k，軟體測驗工程師的漲薪史，給我看哭了

    清明節一過，盲猜大家已經無心上班，在數著日子準備過五一，但一想到銀行卡里的余額……瞬間心情就不美麗了。最近，2023年高校畢業生就業調查顯示，本科畢業月平均起薪為5825元。調查一出，便有很多同學表示自己又被平均了。看著這一資料，不免讓人想到前不久中國青年報的一項調查：近六成大學生認為畢業10年內會 ......

    uj5u.com 2023-04-20 07:44:00 more
  • 最新版本 Stable Diffusion 開源 AI 繪畫工具之中文自動提詞篇

    🎈 標簽生成器 由于輸入正向提示詞 prompt 和反向提示詞 negative prompt 都是使用英文，所以對學習母語的我們非常不友好 使用網址：https://tinygeeker.github.io/p/ai-prompt-generator 這個網址是為了讓大家在使用 AI 繪畫的時候 ......

    uj5u.com 2023-04-20 07:43:36 more
  • 漫談前端自動化測驗演進之路及測驗工具分析

    隨著前端技術的不斷發展和應用程式的日益復雜，前端自動化測驗也在不斷演進。隨著 Web 應用程式變得越來越復雜，自動化測驗的需求也越來越高。如今，自動化測驗已經成為 Web 應用程式開發程序中不可或缺的一部分，它們可以幫助開發人員更快地發現和修復錯誤，提高應用程式的性能和可靠性。 ......

    uj5u.com 2023-04-20 07:43:16 more
  • CANN開發實踐：4個DVPP記憶體問題的典型案例解讀

    摘要：由于DVPP媒體資料處理功能對存放輸入、輸出資料的記憶體有更高的要求（例如，記憶體首地址128位元組對齊），因此需呼叫專用的記憶體申請介面，那么本期就分享幾個關于DVPP記憶體問題的典型案例，并給出原因分析及解決方法。 本文分享自華為云社區《FAQ_DVPP記憶體問題案例》，作者：昇騰CANN。 DVPP ......

    uj5u.com 2023-04-20 07:43:03 more
  • msf學習

    msf學習 以kali自帶的msf為例 一、msf核心模塊與功能 msf模塊都放在/usr/share/metasploit-framework/modules目錄下 1、auxiliary 輔助模塊，輔助滲透（埠掃描、登錄密碼爆破、漏洞驗證等） 2、encoders 編碼器模塊，主要包含各種編碼 ......

    uj5u.com 2023-04-20 07:42:59 more
  • Halcon軟體安裝與界面簡介

    1. 下載Halcon17版本到到本地 2. 雙擊安裝包后 3. 步驟如下 1.2 Halcon軟體安裝 界面分為四大塊 1. Halcon的五個助手 1) 影像采集助手：與相機連接，設定相機引數，采集影像 2) 標定助手：九點標定或是其它的標定，生成標定檔案及內參外參，可以將像素單位轉換為長度單位 ......

    uj5u.com 2023-04-20 07:42:17 more
  • 在MacOS下使用Unity3D開發游戲

    第一次發博客，先發一下我的游戲開發環境吧。 去年2月份買了一臺MacBookPro2021 M1pro(以下簡稱mbp)，這一年來一直在用mbp開發游戲。我大致分享一下我的開發工具以及使用體驗。 1、Unity 官網鏈接： https://unity.cn/releases 我一般使用的Apple ......

    uj5u.com 2023-04-20 07:40:19 more

Copyright © 2010-2020 有解無憂