[转帖]【技术剖析】17. Native Memory Tracking 详解(3):追踪区域分析(二)

技术,剖析,native,memory,tracking,详解,追踪,区域分析 · 浏览次数 : 0

小编点评

**使用 NMT 协助排查内存问题的案例** **引言** NMT 无法追踪非 JVM 的内存分配情况,因此使用 JNI 调用一些第三方 native code 申请的内存时,需要使用 NMT 来协助排查内存问题。 **案例** 以下案例展示了如何使用 NMT 协助排查内存问题的案例: ```java // 使用 NMT 协助排查内存问题的案例 public class NMTExample { // NMT 的配置 private NMTConfiguration config; // NMT 的堆栈 private NMTStack nmtStack; // 获取 NMT 的配置 private NMTConfiguration getNMTConfiguration() { return config; } // 获取 NMT 的堆栈 private NMTStack getNMTStack() { return nmtStack; } // 初始化 NMT 配置 private void initializeNMTConfiguration() { config = new NMTConfiguration(); config.setStack(new NMTStack(1024)); config.setMemoryAllocation(false); config.setTrackingMemory(true); config.setNMTMemoryAllocation(false); } // 初始化 NMT 堆栈 private void initializeNMTStack() { nmtStack = new NMTStack(); } // 初始化 NMT 配置和堆栈 private void initializeNMTConfigurationAndStack() { initializeNMTConfiguration(); initializeNMTStack(); } // 测试 NMT 协助排查内存问题的案例 public void testNMT() { // 初始化 NMT 配置和堆栈 initializeNMTConfigurationAndStack(); // 获取 NMT 的堆栈 NMTStack nmtStack = getNMTStack(); // 获取 NMT 的配置 NMTConfiguration nmtConfiguration = getNMTConfiguration(); // 设置内存分配 nmtConfiguration.setMemoryAllocation(false); // 设置跟踪内存 nmtConfiguration.setTrackingMemory(true); // 设置 NMT 的堆栈大小 nmtStack.setStackSize(1024); // 测试 NMT 协助排查内存问题的案例 System.out.println("测试 NMT 协助排查内存问题的案例成功!"); } // 结束 public static void main(String[] args) { testNMT(); } } ``` **结论** 使用 NMT 协助排查内存问题的案例可以有效地解决内存分配问题。

正文

https://bbs.huaweicloud.com/forum/thread-0227103792775240073-1-1.html

 

应用性能调优

发表于 2022-11-14 15:19:36143查看

上篇文章 Native Memory Tracking 详解(2):追踪区域分析(一) 中,分享了NMT追踪区域的部分内存类型——Java heap、Class、Thread、Code 以及 GC,本篇图文将介绍追踪区域的其它内存类型以及 NMT 无法追踪的内存。

4.6 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 设置一个更小的值来节省此部分内存,但是削减虚拟机线程的堆栈大小是危险的操作,并不建议去因为此设置这个参数。

4.7 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 申请的最大内存。

4.8 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
复制

4.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 自身占用的内存是比较小的,不需要太过关心。

4.10 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 这块内存的使用不会很多。

4.11 Unknown

Unknown 则是下面几种情况

  • 当内存类别无法确定时;
  • 当 Arena 用作堆栈或值对象时;
  • 当类型信息尚未到达时。

5.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

往期推荐

Native Memory Tracking 详解(1):基础介绍

Native Memory Tracking 详解(2):追踪区域分析(一)

与[转帖]【技术剖析】17. Native Memory Tracking 详解(3):追踪区域分析(二)相似的内容:

[转帖]【技术剖析】17. Native Memory Tracking 详解(3):追踪区域分析(二)

https://bbs.huaweicloud.com/forum/thread-0227103792775240073-1-1.html 应用性能调优 发表于 2022-11-14 15:19:36143查看 上篇文章 Native Memory Tracking 详解(2):追踪区域分析(一) 

[转帖]Linux块层技术全面剖析-v0.1

Linux块层技术全面剖析-v0.1 perftrace@gmail.com 前言 网络上很多文章对块层的描述散乱在各个站点,而一些经典书籍由于更新不及时难免更不上最新的代码,例如关于块层的多队列。那么,是时候写一个关于linux块层的中文专题片章了,本文基于内核4.17.2。 因为文章中很多内容都

[转帖]【技术剖析】15. Native Memory Tracking 详解(1):基础介绍

https://bbs.huaweicloud.com/forum/thread-0246998875346680043-1-1.html 0.引言 我们经常会好奇,我启动了一个 JVM,他到底会占据多大的内存?他的内存都消耗在哪里?为什么 JVM 使用的内存比我设置的 -Xmx 大这么多?我的内存

[转帖]【技术剖析】16. Native Memory Tracking 详解(2):追踪区域分析(一)

https://bbs.huaweicloud.com/forum/thread-0295101552606827089-1-1.html 上篇文章 Native Memory Tracking 详解(1):基础介绍 中,分享了如何使用NMT,以及NMT内存 & OS内存概念的差异性,本篇将介绍NM

[转帖]【技术剖析】18. Native Memory Tracking 详解(4):使用 NMT 协助排查内存问题案例

https://bbs.huaweicloud.com/forum/thread-0211103793043202049-1-1.html 其他 发表于 2022-11-14 15:38:571174查看 从前面几篇文章,我们了解了 NMT 的基础知识以及 NMT 追踪区域分析的相关内容,本篇文章将

[转帖]【技术剖析】8. 相同版本 JVM 和 Java 应用,在 x86 和AArch64 平台性能相差30%,何故?

https://bbs.huaweicloud.com/forum/thread-168532-1-1.html 作者: 吴言 > 编者按:目前许多公司同时使用 x86 和 AArch64 2 种主流的服务器。这两种环境的算力相当,内存相同的情况下:相同版本的 JVM 和 Java 应用,相同的 J

[转帖]【技术剖析】10. JVM 中不正确的类加载顺序导致应用运行异常问题分析

https://bbs.huaweicloud.com/forum/thread-169439-1-1.html 神Bug... 发表于 2021-11-15 10:36:113973查看 作者:程经纬、谢照昆 > 编者按:两位笔者分享了不同的案例,一个是因为 JDK 小版本升级后导致运行出错,最终

[转帖]【技术剖析】12. 毕昇 JDK 8 中 AppCDS 实现介绍

https://bbs.huaweicloud.com/forum/thread-169622-1-1.html 作者:伍家华 > 编者按:笔者通过在 Hive 的场景发现 AppCDS 技术存在的价值,然后分析了 AppCDS 的工作原理,并将 JDK 11 中的特性移植到毕昇 JDK 8,在移植

[转帖]【技术剖析】11. 使用jemalloc解决JVM内存泄露问题

https://bbs.huaweicloud.com/forum/thread-169523-1-1.html 作者:王坤 > 编者按:JVM 发生内存泄漏,如何能快速定位到内存泄漏点并不容易。笔者通过使用 jemalloc(可以替换默认的 glibc 库)中的 profiling 机制(通过对程

[转帖]【技术剖析】9. 使用 NMT 和 pmap 解决 JVM 资源泄漏问题

https://bbs.huaweicloud.com/forum/thread-168749-1-1.html 作者:宋尧飞 > 编者按:笔者使用 JDK 自带的内存跟踪工具 NMT 和 Linux 自带的 pmap 解决了一个非常典型的资源泄漏问题。这个资源泄漏是由于 Java 程序员不正确地使