Hey all,
please review this patch that updates the age table logging. The logging now looks like:
[1.946s][info][gc,reloc ] GC(22) y: Age Table:
[1.946s][info][gc,reloc ] GC(22) y: Live Small Medium Large
[1.946s][info][gc,reloc ] GC(22) y: Eden 0M -> 0M 300 -> 300 0 -> 0 0 -> 0
[1.946s][info][gc,reloc ] GC(22) y: Survivor 1 0M -> 0M 2 -> 2 0 -> 0 0 -> 0
[1.946s][info][gc,reloc ] GC(22) y: Survivor 2 0M -> 0M 1 -> 0 0 -> 0 0 -> 0
[1.946s][info][gc,reloc ] GC(22) y: Survivor 3 0M -> 0M 1 -> 1 0 -> 0 0 -> 0
[1.946s][info][gc,reloc ] GC(22) y: Survivor 4 0M -> 0M 0 -> 1 0 -> 0 0 -> 0
The first column is the size of the live objects with the given age and how that has changed since the previous collection. The remaining columns are the number of pages of the given age and how those have changed from the previous collection to the current one (so the format is `<previous> -> <current>`). This makes it easy to spot a change in behavior in objects' lifetimes from one collection to another: if objects have similar lifetimes compared to the previous collection then the distribution of pages should be similar between the current collection and the previous collection.
_Note_: I would like to make the table adapt to live sizes smaller than one megabyte, but that should probably be done for the logging as a whole, not just for the age table.
I also cleaned up some minor stuff as I went along.
Testing:
- [x] Tier 1-3 (macOS-aarch64, Windows-x64, Linux-x64, Linux-aarch64)
- [x] Local testing on macOS-aarch64
Thanks,
Erik
-------------
Commit messages:
- Rework age table logging
Changes: https://git.openjdk.org/zgc/pull/19/files
Webrev: https://webrevs.openjdk.org/?repo=zgc&pr=19&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8306656
Stats: 200 lines in 10 files changed: 104 ins; 52 del; 44 mod
Patch: https://git.openjdk.org/zgc/pull/19.diff
Fetch: git fetch https://git.openjdk.org/zgc.git pull/19/head:pull/19
PR: https://git.openjdk.org/zgc/pull/19
Hello,
First of all, congratulations on the great work with Generational ZGC. We
are having great results.
We run our services using k8s, and a standard setup for the memory of the
containers is to use 85% of the total memory for Java Heap and 15% for the
rest. So, in a service running with 10Gb, 8.5Gb is allocated to the Java
Heap, and 1.5Gb is Off-Heap memory.
When running with G1, 15% of Off-Heap memory is generally enough. But with
Generational ZGC, we see an increase in out-of-memory container errors.
It's not Java Heap Out of Memory, it's out-of-memory in the container. I
started to decrease the ratio between Heap/Off-Heap memory, which was
enough for some cases. However, there are services already running with 45%
of memory allocated Off-Heap and still suffering from errors.
Is it expected that Generational ZGC requires more Off-Heap memory? Our
containers run with around 80Gb of memory each, so for some cases, we are
talking of more than 20Gb allocated Off-Heap in a pod running only the Java
application.
Thanks!
--
Confidentiality note: This e-mail may contain confidential information
from Nu Holdings Ltd and/or its affiliates. If you have received it by
mistake, please let us know by e-mail reply and delete it from your system;
you may not copy this message or disclose its contents to anyone; for
details about what personal information we collect and why, please refer to
our privacy policy
<https://api.mziq.com/mzfilemanager/v2/d/59a081d2-0d63-4bb5-b786-4c07ae26bc7…>.