Yes, GC's internal data structures.
How much reduction there will likely vary depending on the application
(and G1 region size). The type of application that will experience
larger reductions are those applications that have a large number of
cross G1 region references. A cache like type of application usually has
a large number of these since updates to the cache introduce new
references to an older or longer lived object which is likely held in a
different G1 region.
On 5/6/22 4:36 PM, Stefan Reich wrote:
Ah, so the memory sections that are now smaller are basically the GC's
internal data structures, rather than the general heap?
That kind of puts things in perspective. Still a great improvement.
Has it been tested by how much the overall memory footprint of the JVM
decreases in larger benchmarks?
On Fri, 6 May 2022 at 23:28, charlie hunt <charlie.h...@oracle.com> wrote:
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
<https://urldefense.com/v3/__https://tschatzl.github.io/2022/03/14/jdk18-g1-parallel-gc-changes.html__;!!ACWV5N9M2RV99hQ!OKRokskrYA5lROK6mWSdvn5puKnqs34LsTUVTkWX2Rp65OYC5CRMO5pthP_bsdg-msr3P2Q6ag1T55XNqMseOt88jWtWJhKP$>
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
<https://urldefense.com/v3/__http://Gaz.AI__;!!ACWV5N9M2RV99hQ!OKRokskrYA5lROK6mWSdvn5puKnqs34LsTUVTkWX2Rp65OYC5CRMO5pthP_bsdg-msr3P2Q6ag1T55XNqMseOt88jWC6VYLi$>
==
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use@openjdk.java.net
https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
--
== Gaz.AI
<https://urldefense.com/v3/__http://Gaz.AI__;!!ACWV5N9M2RV99hQ!OKRokskrYA5lROK6mWSdvn5puKnqs34LsTUVTkWX2Rp65OYC5CRMO5pthP_bsdg-msr3P2Q6ag1T55XNqMseOt88jWC6VYLi$>
==
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use@openjdk.java.net
https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
