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 295 contents

https://www.youtube.com/watch?v=JdW-Mk_pd2s
Memory API: Patterns, Uses Cases, and Performance (Page last updated May 2025, Added 2025-06-28, Author José Paumard, Publisher Devoxx UK). Tips:

• Updated version of the talk covered here - the same tips are still relevant, but this talk adds that: the Cleaner API is a useful alternative to the deprecated finalize method (for garbage collecting ByteBuffers); the MemorySegment API is low-level and maps directly to CPU operations; MemorySegment access checks bounds, including thread containment for if the arena is closed; MemorySegment cannot directly write to a file, a ByteBuffer view is still required; Arena.ofConfined creates memory segments that are bound to the creating thread and accessing them from another thread will throw a WrongThreadException; an Arena is a virtual grouping of memory segments, not a dedicated memory space.

https://www.youtube.com/watch?v=kwFP-zCLV2M
Mastering JVM Memory Troubleshooting - From OutOfMemoryErrors to Leaks (Page last updated May 2025, Added 2025-06-28, Author Poonam Parhar, Publisher JavaOne). Tips:

• GC manages the Java Heap, Metaspace and Compressed Class Space. Non-GC managed spaces are the Code Cache, runtime memory, native memory. Java objects in the heap can hold references to native memory, these would require explicit release in Java code.
• Symptoms of memory problems include: Out of Memory Error (OOME); Unexpected memory growth (usually an upward sloping sawtooth); Slowness/non-responsiveness (usually from GCs taking longer and being more frequent); Long garbage collection pauses or excessive garbage collection cycles.
• Underlying causes of memory issues include: Inadequately sized memory pools (heap, metaspace); Memory leaks; Explicit GC invocations (System.gc() calls); Excessive use of finalizers.
• Memory issues diagnosis techniques include: Monitor Java heap, Metaspace and Compressed Class Space usage over time; Monitor heap after Full GCs - if insufficient heap is available, either Xmx or metaspace needs to be larger or there is a memory leak; OOME from native memory means JVM or JNI/JVMTI cannot allocate from native memory - this needs a reduction in Java heap, metaspace, compressed class space, number of threads, or thread stack sizes to free up native memory for the current process, or native memory profiling.
• Useful memory diagnostic data: GC logs (Heap and metaspace usage, frequency of GCs, long GC pauses), heap dumps (from JCMD, JMAP, JConsole, JDK Mission Control/ JMC, or JVM option `-XX:+HeapDumpOnOutOfMemoryError`), heap histograms (JVM option `-XX:+PrintClassHistogram`, JCMD (live processes), JMAP, JHSDB (from core files), JMC), Java Flight Recordings (JFRs, `-XX:StartFlightRecording` or use JCMD, leak profiling with `OldObjectSample` event and `-XX:FlightRecorderRecordingPathToGCRoots=true`), NMT output (`-XX:NativeMemoryTracking` option at `summary` or `detail` level), data from OS monitoring tools (PS, top, pmap, perfmon, VMmap), and core files.
• Useful memory analysis tools: see GC log analysers in the tools links at the top of the page, look for several full GCs, GCs with long pauses, or too frequent GCs; For heap dumps see Heap dump analysers in the tools links at the top of the page; for NMT collect a baseline using JCMD, then compare with subsequent detailed diffs or summary deltas to see changes in allocation categories (e.g., class category growth indicating increased class loading).

https://www.youtube.com/watch?v=a5MFIu6d0so
Efficient Software: A Developer's Manual for Saving The World (Page last updated May 2025, Added 2025-06-28, Author Holly Cummins, Publisher Devoxx). Tips:

• Efficiency is about doing less, not more. Efficient software does less of the stuff you don't actually need, getting rid of bloat, pointless spinning, and task repetition, ie doing what you need using fewer resources. Reducing resource requirements is not only more efficient but importantly cheaper too!
• Shutdown unused resources automatically, eg overnight when no one is using them; find and remove no longer used cloud resources.
• Use frameworks that are targeted at low resource usage.
• For code performance engineering focus on algorithms and architecture.
• Language choice matters for efficiency. Java is a in a sweet spot of very efficient and very productive.
• Move runtime work to build time if possible.
• With containers, applications are downloaded more often, so optimize for caching layers.
• Move away from fat jars and use layered container architectures. Structure layers so that changing layers are the last ones, minimizing re-downloads.
• Remove unused code/dependencies - if code isn't used, don't include it.
• Be guided by data, not intuition, for performance tuning. Measure the right thing, not the easiest thing. Do high-level analysis first to identify the biggest problems, then drill down.
• Treat measuring like other expensive, annoying tasks: do more of it by investing in automation and expertise.
• The optimization process is: monitor, profile, find bottlenecks, fix, repeat.
• Profiling tools include: Method profilers (eg Async Profiler); GC analysis (see GC log analysers in the tools links at the top of the page); Heap analysis (see Heap dump analysers in the tools links at the top of the page).
• Aim for 70-80% utilization of systems as the "sweet spot", over-provisioning is wasteful. Invest in elasticity - capacity should go up and down with load to maintain good utilization.
• Automate turning things off. Optimize batch jobs left running all the time, and systems running 24/7 despite only being used during specific hours.
• Simple automation can be remarkably effective: Machines self-destructing after 2 weeks unless extended; Shell scripts to turn things off overnight; Use Scream Tests - shut off servers to see if they are being used (but be cautious here).
• Define quantifiable success with SLAs (e.g., 99% of requests under 100ms, run on a T2 micro instance, cost per transaction less than X). Stop when the goal is reached and move on to other things.
• When improving efficiency without a strict SLA, look for diminishing returns - stop before reaching the point of "wringing performance out of a stone".
• Do things that save a lot of money for little effort, avoid things that save little for much effort.

Jack Shirazi Back to newsletter 295 contents