Hi Stefan,
The graph Thomas shows in his blog is the GC part of the NMT output
which does not include metadata.
The GC part of NMT output includes native memory allocated on behalf of
the GC itself such as a card table or remembered set .. those things
that GC needs to do its work. The native memory allocated for the Java
heap are in the "Java Heap" section of the NMT output. Class metadata is
in the "Class" section of the NMT output.
There is a "Native Memory Tracking Memory Categories" table that lists
the sections / categories reported by NMT and a description of each at:
https://docs.oracle.com/en/java/javase/17/troubleshoot/diagnostic-tools.html#GUID-5EF7BB07-C903-4EBD-A9C2-EC0E44048D37
hths,
Charlie
On 5/6/22 2:13 PM, Stefan Reich wrote:
I'm right now just trying to get over how amazing this graph is:
https://tschatzl.github.io/2022/03/14/jdk18-g1-parallel-gc-changes.html
35-40% savings in memory use just by using JDK 18??? Who would have
expected such a major improvement after 17 iterations of the language!
Just so I'm sure I'm reading it correctly... the graph basically shows
the Java heap's memory footprint in terms of committed native memory.
Right?
So it would include Eden, tenured generations, humongous objects, but
not metadata and code. Is that correct?
Basically tell me how much I should celebrate this. lol
I did switch another small, pretty crammed (8 GB RAM) server over to
JDK 18 and it does feel like there's a lot more memory available on it
now and everything is a lot faster too.
Cheers
Stefan
--
== Gaz.AI <http://Gaz.AI> ==
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use@openjdk.java.net
https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use@openjdk.java.net
https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
