RFR: JDK-8301749: Tracking malloc pooled memory size [v3]
Johan Sjölen
jsjolen at openjdk.org
Thu Feb 9 10:38:34 UTC 2023
> This PR implements `os::malloc_info` by calling into glibc's `malloc_info` and provides a JCmd for asking the JVM to call `malloc_info` and print out the results. The user can make an informed decision regarding heap trimming by parsing the output of the JCmd. I wanted to avoid parsing the XML inside of the JVM , as this functionality may turn out to be "good enough". A future enhancement would be for the JVM to make this informed decision by parsing the output. Another may be to present this with other data, for example in NMT.
>
> @tstuefe, I think you'd be interested in this PR as it builds upon your `trim_native_heap` functionality.
>
> I'm using weak symbols (as per ELF) in order to compile this for both GLibc and Musl.
>
> The original bug description is this:
>
>>Memory not allocated via NMT and uncommitted memory contributes to a discrepancy between NMT and RSS.
> It can be hard to distinguish between these cases.
> If the VM can determine the amount of pooled memory by malloc it would help with both determining if a trim_native_memory is needed, or there are some allocations happening outside of NMT.
>>
>>It would be good if the VM can summarize the malloc pooled memory by using e.g. malloc_info(3).
>>
>>We can thus more precise account for RSS value.
Johan Sjölen has updated the pull request incrementally with one additional commit since the last revision:
Small nits
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/12455/files
- new: https://git.openjdk.org/jdk/pull/12455/files/a209d711..ea112ae1
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=12455&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=12455&range=01-02
Stats: 9 lines in 2 files changed: 2 ins; 2 del; 5 mod
Patch: https://git.openjdk.org/jdk/pull/12455.diff
Fetch: git fetch https://git.openjdk.org/jdk pull/12455/head:pull/12455
PR: https://git.openjdk.org/jdk/pull/12455
More information about the hotspot-runtime-dev
mailing list