RFR: JDK-8293114: GC should trim the native heap
Zhengyu Gu
zgu at openjdk.org
Fri Sep 2 20:07:40 UTC 2022
On Thu, 1 Sep 2022 05:25:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
> Hi Zhengyu,
>
> > @tstuefe Nice work!
>
> Thanks :)
>
> > I also looked into memory usage recently, I found that `os::print_os_info()` is very usefully. I would like to purpose to add a diagnostics flag, e.g. `PrintProcessInfoAtExit` to capture some insights of the process, such as `RSS`, `Peak RSS`, `C-Heap` and `C-Heap Retained`.
>
> A small problem with "C-Heap Retained" is that it also contains blocks that are either trimmed or have never been (fully) paged in, meaning, that number may not relate 1:1 to RSS. Glibc observability is really annoying.
>
> About the "AtExit", in our SAP JVM I added a simple "DumpInfoAtExit", which prints out what "jcmd VM.info" would give you. Basically, a hs-err file without the err part. That contains a whole lot of information, including NMT and process memory information. That may be a better way than adding individual XXAtExit flags, what do you think?
I am not sure, because it overlaps many other XXAtExit options?
>
> Another thing I would like to do is to enable Peak usage numbers in NMT for release builds too. That way one can see at VM exit how much memory each subsystem used.
>
> > Here are some numbers I captured
> > C-Heap Outstanding (K) C-Heap Retained (K)
> > Compiler 106387 271692
> > Sunflow 103882 173929
> > Compress 37794 11605
> > CrytioAes 37579 30580
> > CryptoRsa 38318 73001
> > CryptoSignVerify 37790 38769
> > Derby 55389 186954
> > MpegAudio 40280 71743
> > ScimarkFFT.large 36698 8945
> > ScimarkFFT.small 37071 10824
> > ScimarkLU.large 38018 8529
> > ScimarkLU.small 39198 8585
> > ScimarkMonteCarlo 36946 6529
> > ScimarkSOR.large 36648 8787
> > ScimarkSOR.small 36569 9078
> > ScimarkSparse.large 36745 9182
> > ScimarkSparse.small 37253 8574
> > Serial. 38652 127231
> > Sunflow.test. 45450 56657
> > XmlTransform. 83116 289431
> > XmlValidation 59883 59883
> >
> > I captured the number at JVM exit, so it might not reflect runtime characters.
> > But some number is quite interesting, e.g. `Derby` retained set is about x3 of outstanding set.
>
> Interesting, since it means malloc peaks are more common then we think. All the more reason to have a feature like this, to trim the C-heap.
>
> Cheers, Thomas
-------------
PR: https://git.openjdk.org/jdk/pull/10085
More information about the hotspot-dev
mailing list