JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 310 contents

https://www.youtube.com/watch?v=4kEh8hxAP4U
Java AOT in Production at Netflix (Page last updated May 2026, Added 2026-09-28, Author Martin Chalupa, Ian Brown, Publisher JavaONE). Tips:

• Train AOT caches as close to production as possible using representative traffic.
• Use canary deployments for AOT training when they match production but have bounded lifetimes.
• Match the exact JDK version and JVM configuration between training and production for AOT.
• Match the operating system, CPU architecture, and relevant CPU features for AOT training.
• For AOT training use fully packaged JARs; avoid class directories in the training classpath.
• Hash the classpath and reject AOT archives that do not match the deployed application.
• Include cluster or workload identity when selecting an AOT archive.
• Integrate AOT generation and retrieval into existing deployment and startup tooling.
• Ensure training applications terminate gracefully so archive generation completes without failure.
• Keep the archive uploader alive after the training JVM exits.
• Account for concurrent training JVMs to avoid memory oversubscription and OOM kills.
• Sign AOT archives and verify their digest before loading them in production.
• Compress AOT archives and parallelize transfers only when sufficient bandwidth is available.
• Keep AOT archive downloads off the startup critical path where possible.
• Measure net startup improvement, including AOT archive download and decompression time.

https://www.youtube.com/watch?v=mng0DTspxpQ
Post-Mortem JVM Crash Analysis with jcmd (Page last updated May 2026, Added 2026-09-28, Author Fairoz Matte, Publisher JavaONE). Tips:

• Preserve both the `hs_err_pid` log and OS core/minidump after a JVM crash.
• Check the problematic frame, signal, thread stacks, VM arguments, and system details first.
• Enable core dumps before incidents occur; they contain the crashed process's memory image.
• Keep JFR continuously enabled to capture events leading up to sudden crashes.
• Use `jcmd` as the primary diagnostic interface for live JVMs.
• Use native debuggers for symbols and native frames, but expect limited Java-level visibility.
• Use class histograms to identify unexpectedly numerous or memory-heavy objects at crash time.
• Extract a heap dump from the core when deeper retention analysis is required.
• Inspect GC state, heap regions, metaspace, code cache, and class-loader statistics.
• Record the exact JDK/JVM version and startup arguments used by the crashed process.
• Preserve the exact JVM binary that generated the core; post-mortem revival requires it. Reproduce the production OS and system-library environment when analyzing cores elsewhere.
• Ensure analysis hosts have enough memory and storage for potentially huge core and heap files.
• Treat core analysis as read-only state inspection; commands requiring live threads cannot work.

https://www.youtube.com/watch?v=vu0XEBplqpg
The Power of JDK Flight Recorder: Efficient Profiling and Troubleshooting for Java Applications (Page last updated August 2026, Added 2026-09-28, Author Mikael Vidstedt, Publisher JavaONE). Tips:

• Keep JFR continuously enabled in production; its default overhead is typically under 1%.
• Start with the built-in `default.jfc` configuration for low-overhead JFR diagnostics; use `profile.jfc` temporarily when deeper profiling detail is required. Copy built-in configuration files before customizing them; never edit the originals.
• Retain enough JFR recording history to capture events preceding an incident, but bound recording memory, disk size, and retention with file rotation.
• Filter short, uninteresting JFR events using duration thresholds; Throttle high-frequency events to control recording size and overhead.
• Limit stack-trace depth for JFR unless deeper traces are necessary.
• Use `jcmd JFR.start`, `JFR.dump`, and `JFR.stop` on already-running JVMs.
• Begin investigations with aggregated JFR views before inspecting raw events.
• Correlate latency incidents with CPU load, hot methods, GC pauses, and I/O.
• Capture `path-to-gc-roots` in JFR and inspect old-object samples when investigating leaks.
• Add custom JFR events to correlate business operations with JVM activity.
• Dump JFR recordings automatically when alerts, errors, or latency spikes occur.

Jack Shirazi Back to newsletter 310 contents