Memory footprint of a Java process
summary
Xmx=4g does not guarantee a 4 GB RSS; Linux lazy commit means Xms can be unbacked until -XX:+AlwaysPreTouch touches pages, and the JVM adds sizeable native pools: compressed class space defaults to 1GB, default thread stack is 1MB and 500 threads can cost hundreds of MB. Use top/pmap, jcmd native memory tracking (NMT ~5–10% overhead), async-profiler and jemalloc's profiler to find 64 MB malloc arena fragmentation, unclosed zip/input streams causing mmap leaks, and logger-driven page-cache growth — jemalloc fixed fragmentation in production.
AI-written summary · about
chapters (27)
- 0:00Start
- 1:00Containerized applications
- 1:55Java & resource limits
- 2:52Container support?
- 4:01Footprint of a Java process
- 6:28Native Memory Tracking
- 8:56Java Heap & GC
- 10:22GC memory overhead
- 11:27Heap size
- 13:38Adaptive size policy
- 15:11Uncommit: G1
- 15:40Uncommit: Shenandoah
- 18:18ClassLoader statistics
- 19:00Metaspace tuning
- 20:12Compiler
- 21:52Tiered Compilation
- 23:35Monitoring
- 24:38Thread stack
- 25:49Native Memory: Symbols
- 26:08Symbol tables stats
- 27:05What's this?
- 27:59Direct Byte Buffers
- 31:28Is Heap ByteBuffer better?
- 34:06Native memory leak
- 34:45Memory map
- 36:56Alternative allocators
- 37:58jemalloc profiler
related talks
51mOOMs!... I did it again
48mJava Memory Management Best Practices
43mWho Ate My RAM?
43mTroubleshooting Memory Problems in Java Applications
34mTroubleshooting Native Memory Issues in Java Applications
45mScooby RAM, where are you?
02h 41mCures for OOMKills, Warm-ups, and Slowness in JVM Containers
01h 32mTuning Large Scale Java Platforms