RFR: JDK-8317683: Add JIT memory statistics [v5]
Vladimir Kozlov
kvn at openjdk.org
Fri Oct 13 22:07:52 UTC 2023
On Fri, 13 Oct 2023 10:15:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
>> This proposal adds a way to monitor C1/C2 memory usage per compilation.
>>
>> We are flying a bit blind there: NMT is okay for initial triaging but no help when digging deeper into compiler footprint. NMT shows how much native memory the JIT uses but lumps together footprints from concurrent compilations, making its peak values arbitrary. And we have no way to associate the NMT numbers with individual allocations.
>>
>> The statistic added by this patch shows footprint *per compilation*. It measures memory spikes per thread for a single compilation. It then presents them with additional information, e.g., the node count (for C2).
>>
>> Example printout:
>>
>>
>> 112703:
>> Compilation memory statistics
>>
>> Legend:
>> total : memory allocated via arenas while compiling
>> NA : ...how much in node arenas (if c2)
>> RA : ...how much in resource areas
>> #nodes : ...how many nodes (if c2)
>> time : time of last compilation (sec)
>> type : compiler type
>> #rc : how often recompiled
>> thread : compiler thread
>>
>> total NA RA #nodes time type #rc thread method
>> 30273336 6383040 18027000 18257 1,979 c2 2 0x00007f6f0c136460 java/lang/ClassLoader.loadClass((Ljava/lang/String;)Ljava/lang/Class;)
>> 27690456 5892160 16211800 15179 3,643 c2 2 0x00007f6f0c0433e0 org/springframework/cache/interceptor/CacheOperationSourcePointcut.matches((Ljava/lang/reflect/Method;Ljava/lang/Class;)Z)
>> ...
>> ...
>>
>>
>> [full example printout here](https://github.com/openjdk/jdk/files/12853477/compiler-statistic-petclinic.txt)
>>
>> #### Usage
>>
>> The statistic needs to be enabled with a new compile command (`-XX:CompileCommand="CollectMemStat,*.*` or `-XX:CompileCommand="PrintMemStat,*.*"`).
>>
>> It then can be printed with a new jcmd: `jcmd xxx Compiler.memory`.
>>
>> `PrintMemStat` also prints the usage out after compilation and again, as sorted table, at VM shutdown.
>>
>> #### Technical details
>>
>> The patch exploits the fact that compilers use arenas almost exclusively. It hooks into `Arena::grow()` to track allocations. That makes memory tracking very cheap at an acceptable loss in fidelity (we only track arena chunk allocations, not individual Arena allocations).
>>
>> Peak values are tracked per compiler thread. That works since all arenas used during compilation are associated with a compiler thread and never change that association during the compilation.
>>
>> We measure total footprint...
>
> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>
> - Change to single option MemStat
> - Merge branch 'master' into arena-per-thread-stats-for-compiler
> - Feedback Andrew
> - remove stray newlines
> - MemStat->CollectMemStat
> - Feedback Vladimir
> - Compilation memory statistic
My testing of v04 passed.
-------------
Marked as reviewed by kvn (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/16076#pullrequestreview-1677457236
More information about the hotspot-compiler-dev
mailing list