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