4.6 Compiler
Compiler 就是 JIT 编译器线程在编译 code 时本身所使用的内存。查看 NMT 详情:
[0x0000ffff93e3acc0]Thread::allocate(unsignedlong,bool,MemoryType)+0x348 [0x0000ffff9377a498]CompileBroker::make_compiler_thread(charconst*,CompileQueue*,CompilerCounters*,AbstractCompiler*,Thread*)+0x120 [0x0000ffff9377ce98]CompileBroker::init_compiler_threads(int,int)+0x148 [0x0000ffff9377d400]CompileBroker::compilation_init()+0xc8 (malloc=37KBtype=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 voidCompileBroker::compilation_init(){ ...... //Noneedtoinitializecompilationsystemifwedonotuseit. if(!UseCompiler){ return; } #ifndefSHARK //Settheinterfacetothecurrentcompiler(s). intc1_count=CompilationPolicy::policy()->compiler_count(CompLevel_simple); intc2_count=CompilationPolicy::policy()->compiler_count(CompLevel_full_optimization); ...... //StarttheCompilerThreads 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 voidArguments::set_tiered_flags(){ //Withtiered,setdefaultpolicytoAdvancedThresholdPolicy,whichis3. if(FLAG_IS_DEFAULT(CompilationPolicyChoice)){ FLAG_SET_DEFAULT(CompilationPolicyChoice,3); } ...... } #hotspot/src/share/vm/runtime/compilationPolicy.cpp //Determinecompilationpolicybasedoncommandlineargument voidcompilationPolicy_init(){ CompilationPolicy::set_in_vm_startup(DelayCompilationDuringStartup); switch(CompilationPolicyChoice){ ...... case3: #ifdefTIERED CompilationPolicy::set_policy(newAdvancedThresholdPolicy()); #else Unimplemented(); #endif break; ...... CompilationPolicy::policy()->initialize(); }
此时我们默认开启了分层编译,所以 CompilationPolicyChoice 为 3 ,编译策略选用的是 AdvancedThresholdPolicy,查看相关源码(compilationPolicy_init -> AdvancedThresholdPolicy::initialize):
#hotspot/src/share/vm/runtime/advancedThresholdPolicy.cpp voidAdvancedThresholdPolicy::initialize(){ //Turnonergonomiccompilercountselection if(FLAG_IS_DEFAULT(CICompilerCountPerCPU)&&FLAG_IS_DEFAULT(CICompilerCount)){ FLAG_SET_DEFAULT(CICompilerCountPerCPU,true); } intcount=CICompilerCount; if(CICompilerCountPerCPU){ //Simplelognseemstogrowtooslowlyfortiered,trysomethingfaster:logn*loglogn intlog_cpu=log2_int(os::active_processor_count()); intloglog_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-flagCICompilerCount-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_
需要注意的是, {tmpdir}/hsperfdata_
我们在操作 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 publicstaticByteBufferallocateDirect(intcapacity){ returnnewDirectByteBuffer(capacity); } #DirectByteBuffer.java DirectByteBuffer(intcap){//package-private ...... longbase=0; try{ base=unsafe.allocateMemory(size); } ...... #Unsafe.java publicnativelongallocateMemory(longbytes); #hotspot/src/share/vm/prims/unsafe.cpp UNSAFE_ENTRY(jlong,Unsafe_AllocateMemory(JNIEnv*env,jobjectunsafe,jlongsize)) UnsafeWrapper("Unsafe_AllocateMemory"); size_tsz=(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 的限制):
importjava.nio.ByteBuffer; publicclassByteBufferTest{ privatestaticint_1M=1024*1024; privatestaticByteBufferallocateBuffer_1=ByteBuffer.allocateDirect(128*_1M); privatestaticByteBufferallocateBuffer_2=ByteBuffer.allocateDirect(256*_1M); publicstaticvoidmain(String[]args)throwsException{ System.out.println("MaxDirectmemory:"+sun.misc.VM.maxDirectMemory()+"bytes"); System.out.println("Directallocation:"+(allocateBuffer_1.capacity()+allocateBuffer_2.capacity())+"bytes"); System.out.println("Nativememoryused:"+sun.misc.SharedSecrets.getJavaNioAccess().getDirectBufferPool().getMemoryUsed()+"bytes"); Thread.sleep(6000000); } }
查看输出:
MaxDirectmemory:1073741824bytes Directallocation:402653184bytes Nativememoryused:402653184bytes
查看 NMT 详情:
-Internal(reserved=405202KB,committed=405202KB) (malloc=405170KB#3605) (mmap:reserved=32KB,committed=32KB) ...... [0x0000ffffbb599190]Unsafe_AllocateMemory+0x1c0 [0x0000ffffa40157a8] (malloc=393216KBtype=Internal#2) ...... [0x0000ffffbb04b3f8]GenericGrowableArray::raw_allocate(int)+0x188 [0x0000ffffbb4339d8]PerfDataManager::add_item(PerfData*,bool)[clone.constprop.16]+0x108 [0x0000ffffbb434118]PerfDataManager::create_string_variable(CounterNS,charconst*,int,charconst*,Thread*)+0x178 [0x0000ffffbae9d400]CompilerCounters::CompilerCounters(charconst*,int,Thread*)[clone.part.78]+0xb0 (malloc=3KBtype=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 中来重用字符串。
编写一个简单的示例:
publicclassStringTableTest{ publicstaticvoidmain(String[]args)throwsException{ while(true){ Stringstr=newString("StringTestData_"+System.currentTimeMillis()); str.intern(); } } }
启动程序后我们可以使用 jcmd
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(unsignedint)+0x1a0 [0x0000ffffa2aef558]Hashtable::new_entry(unsignedint,oopDesc*)+0x28 [0x0000ffffa2fbff78]StringTable::basic_add(int,Handle,unsignedshort*,int,unsignedint,Thread*)+0xe0 [0x0000ffffa2fc0548]StringTable::intern(Handle,unsignedshort*,int,Thread*)+0x1a0 (malloc=17592KBtype=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(unsignedint)+0x1a0 [0x0000ffffa30c1558]Hashtable::new_entry(unsignedint,oopDesc*)+0x28 [0x0000ffffa3591f78]StringTable::basic_add(int,Handle,unsignedshort*,int,unsignedint,Thread*)+0xe0 [0x0000ffffa3592548]StringTable::intern(Handle,unsignedshort*,int,Thread*)+0x1a0 (malloc=18008KBtype=Symbol+17416KB#2251+2177)
可以发现 StringTable 的大小是超过 10M 的,查看该参数的作用:
#hotsopt/src/share/vm/classfile/symnolTable.hpp StringTable():RehashableHashtable((int)StringTableSize, sizeof(HashtableEntry )){} StringTable(HashtableBucket *t,intnumber_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
StringTablestatistics: Numberofbuckets:16777216=134217728bytes,each8 Numberofentries:39703=635248bytes,each16 Numberofliterals:39703=2849304bytes,avg71.765 Totalfootprsize_t:=137702280bytes Averagebucketsize:0.002 Varianceofbucketsize:0.002 Std.dev.ofbucketsize:0.049 Maximumbucketsize:2 SymbolTablestatistics: Numberofbuckets:20011=160088bytes,each8 Numberofentries:20133=483192bytes,each24 Numberofliterals:20133=753832bytes,avg37.443 Totalfootprint:=1397112bytes Averagebucketsize:1.006 Varianceofbucketsize:1.013 Std.dev.ofbucketsize:1.006 Maximumbucketsize: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 voidMemTracker::init(){ NMT_TrackingLevellevel=tracking_level(); ...... } #/hotspot/src/share/vm/services/memTracker.hpp staticinlineNMT_TrackingLeveltracking_level(){ if(_tracking_level==NMT_unknown){ //Nofencingisneededhere,sinceJVMisinsingle-threaded //mode. _tracking_level=init_tracking_level(); _cmdline_tracking_level=_tracking_level; } return_tracking_level; } #/hotspot/src/share/vm/services/memTracker.cpp NMT_TrackingLevelMemTracker::init_tracking_level(){ NMT_TrackingLevellevel=NMT_off; ...... if(os::getenv(buf,nmt_option,sizeof(nmt_option))){ if(strcmp(nmt_option,"summary")==0){ level=NMT_summary; }elseif(strcmp(nmt_option,"detail")==0){ #ifPLATFORM_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; } returnlevel; } #/hotspot/src/share/vm/services/memTracker.cpp boolMallocTracker::initialize(NMT_TrackingLevellevel){ if(level>=NMT_summary){ MallocMemorySummary::initialize(); } if(level==NMT_detail){ returnMallocSiteTable::initialize(); } returntrue; } voidMallocMemorySummary::initialize(){ assert(sizeof(_snapshot)>=sizeof(MallocMemorySnapshot),"SanityCheck"); //Usesplacementnewoperatortoinitializestaticarea. ::new((void*)_snapshot)MallocMemorySnapshot(); } # boolVirtualMemoryTracker::initialize(NMT_TrackingLevellevel){ if(level>=NMT_summary){ VirtualMemorySummary::initialize(); } returntrue; }
我们执行的 jcmd
summary 时使用 MemSummaryReporter::report() 获取 VirtualMemoryTracker、MallocMemorySummary 等储存的数据;
detail 时使用 MemDetailReporter::report() 获取 VirtualMemoryTracker、MallocMemorySummary、MallocSiteTable 等储存的数据。
#hotspot/src/share/vm/services/nmtDCmd.cpp voidNMTDCmd::execute(DCmdSourcesource,TRAPS){ ...... if(_summary.value()){ report(true,scale_unit); }elseif(_detail.value()){ if(!check_detail_tracking_level(output())){ return; } report(false,scale_unit); } ...... } voidNMTDCmd::report(boolsummaryOnly,size_tscale_unit){ MemBaselinebaseline; if(baseline.baseline(summaryOnly)){ if(summaryOnly){ MemSummaryReporterrpt(baseline,output(),scale_unit); rpt.report(); }else{ MemDetailReporterrpt(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,unsignedlong)+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, "Useonlymalloc/freeforallocation(noresourcearea/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_tx,AllocFailTypealloc_failmode=AllocFailStrategy::EXIT_OOM){ assert(is_power_of_2(ARENA_AMALLOC_ALIGNMENT),"shouldbeapowerof2"); x=ARENA_ALIGN(x); //debug版本限制 debug_only(if(UseMallocOnly)returnmalloc(x);) if(!check_for_overflow(x,"Arena::Amalloc",alloc_failmode)) returnNULL; NOT_PRODUCT(inc_bytes_allocated(x);) if(_hwm+x>_max){ returngrow(x,alloc_failmode); }else{ char*old=_hwm; _hwm+=x; returnold; } }
可以发现,即使我们成功开启了 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(unsignedlong,AllocFailStrategy::AllocFailEnum)+0x158 [0x0000ffffb7d15f58]Arena::grow(unsignedlong,AllocFailStrategy::AllocFailEnum)+0x50 [0x0000ffffb7fc4888]Dict::Dict(int(*)(voidconst*,voidconst*),int(*)(voidconst*),Arena*,int)+0x138 [0x0000ffffb85e5968]Type::Initialize_shared(Compile*)+0xb0 (malloc=32KBtype=ArenaChunk#1) ......
# debug版本 JVM ,启动参数添加:-XX:+UseMallocOnly ...... [0x0000ffff8dfae910]Arena::malloc(unsignedlong)+0x74 [0x0000ffff8e2cb3b8]Arena::Amalloc_4(unsignedlong,AllocFailStrategy::AllocFailEnum)+0x70 [0x0000ffff8e2c9d5c]Dict::Dict(int(*)(voidconst*,voidconst*),int(*)(voidconst*),Arena*,int)+0x19c [0x0000ffff8e97c3d0]Type::Initialize_shared(Compile*)+0x9c (malloc=5KBtype=ArenaChunk#1) ......
我们可以清晰地观察到调用链的不同,即前者还是使用 ChunkPool::allocate 的方式来申请内存,而后者则使用 Arena::malloc 的方式来申请内存,查看 Arena::malloc 代码:
#hotspot/src/share/vm/memory/allocation.cpp void*Arena::malloc(size_tsize){ assert(UseMallocOnly,"shouldn'tcall"); //usemalloc,butsavepointerinres.areaforlaterfreeing 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 //debuggingcode inlinevoidArena::free_all(char**start,char**end){ for(char**p=start;p< end; p++) if (*p) os::free(*p); }
虽然 JVM 为我们提供了两种方式来管理 Arena Chunk 的内存:
通过 ChunkPool 池化交由 JVM 自己管理;
直接通过 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,协助追踪内存的分配。
审核编辑:刘清
-
编译器
+关注
关注
1文章
1624浏览量
49108 -
JVM
+关注
关注
0文章
158浏览量
12220 -
虚拟机
+关注
关注
1文章
914浏览量
28160
原文标题:Native Memory Tracking 详解(3):追踪区域分析(二)
文章出处:【微信号:openEulercommunity,微信公众号:openEuler】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论