on heap overhead of ZGC
Alen Vrečko
alen.vrecko at gmail.com
Wed Apr 19 11:38:13 UTC 2023
Hello everyone.
I did my best to search the web for any prior discussion on this. Haven't
found anything useful.
I am trying to understand why there is a noticeable difference between the
size of all objects on the heap and the heap used (after full GC). The heap
used size can be 10%+ more than the size of of all live objects.
Let's say I want to fill 1 GiB heap with 4MiB byte[] objects.
Naively I'd imagine I can store 1 GiB / 4MiB = 256 such byte[] on the heap.
(I made a simple program that just allocates byte[], stores it in a list,
does GC and waits (so I can do jcmd or similar), nothing else)
With EpsilonGC -> 255x 4MiB byte[] allocations, after this the app crashes
with out of memory
With SerialGC -> 246x
With ParallelGC -> 233x
With G1GC -> 204x
With ZGC -> 170x
For example in the ZGC case, where I have 170x of 4MiB byte[] on the heap.
GC.heap_info:
ZHeap used 1022M, capacity 1024M, max capacity 1024M
Metaspace used 407K, committed 576K, reserved 1114112K
class space used 24K, committed 128K, reserved 1048576K
GC.class_histogram:
Total 15118 713971800 (~714M)
In this case does it mean ZGC is wasting 1022M - 714M = 308M for doing its
"thing"? This is like 1022/714= 43% overhead?
This example might be convoluted and atypical of any production environment.
I am seeing the difference between live set and heap used in production at
around 12.5% for 3 servers looked at.
Is there any other way to estimate the overhead apart from looking at the
difference between the live set and heap used? Does ZGC have any internal
statistic of the overhead?
I'd prefer not to assume 12.5% is the number to use and then get surprised
that in some case it might be 25%?
Do you have any recommendations regarding ZGC overhead when estimating heap
space?
Thank you
Alen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/zgc-dev/attachments/20230419/d51edf53/attachment.htm>
More information about the zgc-dev
mailing list