-
Enhancement
-
Resolution: Unresolved
-
P4
-
25
A common problem with JDK upgrades is changing GCs, e.g. dropping CMS in favor of G1/Parallel, or switching default Parallel to G1, or switching from Serial to G1 due to ergonomic differences. Often, our customers discover large discrepancies in memory taken by internal GC structures. It would be good for us to develop tests that verify we are not breaking through reasonable caps for GC memory overheads, so we do not introduce extra regressions there.
Fortunately, withJDK-8291878, we can write straight-forward GC tests that cap the memory limits for GC structures and fail if we pass a reasonable ceiling.
For example:
% build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m -XX:+UseG1GC -XX:NativeMemoryTracking=summary -XX:+UnlockDiagnosticVMOptions -XX:MallocLimit=gc:80m Alloc.java 2>&1 | tee out
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (mallocTracker.cpp:148), pid=7102, tid=7104
# fatal error: MallocLimit: reached category "mtGC" limit (triggering allocation size: 1024K, allocated so far: 81565K, limit: 81920K)
The tests would likely need to explore the different combinations of heap sizes, GC thread counts, ActiveProcessorCount-s.
Fortunately, with
For example:
% build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m -XX:+UseG1GC -XX:NativeMemoryTracking=summary -XX:+UnlockDiagnosticVMOptions -XX:MallocLimit=gc:80m Alloc.java 2>&1 | tee out
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (mallocTracker.cpp:148), pid=7102, tid=7104
# fatal error: MallocLimit: reached category "mtGC" limit (triggering allocation size: 1024K, allocated so far: 81565K, limit: 81920K)
The tests would likely need to explore the different combinations of heap sizes, GC thread counts, ActiveProcessorCount-s.
- relates to
-
JDK-8352569 NMT: mmap limits
-
- Open
-