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

https://www.youtube.com/watch?v=wwgvDDuJwtk
Production profiling with JDK Flight Recorder & JDK Mission Control (Page last updated September 2021, Added 2021-09-28, Author Jean-Philippe Bempel, Publisher Madrid JUG). Tips:

• JDK Flight Recorder records JVM information with low overhead (typically under 1%). It is safe to use in production. Does not undo optimizations and isn't affected by safepoints. Data is typically 2MB/minute (approx 100k events).
• JMC includes parsers and analysis tools for JFR recordings which can be used independently of JMC - libraries are available from maven central.
• JMC agent allows you to declaratively insert custom events to your application.

https://www.youtube.com/watch?v=EFkpmFt61Jo
Journey to the Centre of the JVM (Page last updated August 2021, Added 2021-09-28, Author Daniel Spiewak, Publisher ChariotSolutions). Tips:

• Variable data being acted on are held in caches (L1, L2, etc) as close to the CPU as possible. Without explicit memory barriers (eg volatile modifier), the data will not be synchronized across different caches on different cores, which means a change to a simple variable data value may not be seen in other threads for a long time.
• Volatile variables cause other changes to be flushed when they get flushed. This means if you are careful you can use a volatile operation to flush other changes on non-volatile fields, across threads.
• compare-and-swap is implemented equivalent to a volatile read and write operation on updates, but only a read operation (no write) if the compare fails. So it won't flush memory if the compare fails.
• x86 has stronger memory semantics than some other CPU architectures like ARM, many applications have subtle concurrency bugs that are hidden by the x86 memory model which may be exposed on other CPU architectures like ARM, so you should be careful to fully load/stress/concurrency test on any new CPU architecture for your application.

https://www.youtube.com/watch?v=by4M_zi9HnU
State of Java Elasticity. Tuning Java Efficiency (Page last updated November 2020, Added 2021-09-28, Author Ruslan Synytsky, Publisher JDD). Tips:

• The JVM holds memory for the heap which is unavailable to other applications even if the JVM doesn't use it all. Some garbage collectors are better than others at minimizing this unused heap and making the memory available outside the JVM, though mostly from full GCs, not minor GCs.
• The JVM has 3 memory areas: JVM native (thread stacks, memory-mapped files, nio buffers, shared kibs); the heap (objects); off-heap (direct byte buffers, code caches, metaspace). OOMEs typically occur when the heap runs out of space, though also when other areas run out of native space like too many thread stacks or Metaspace can't expand further. For JVMs in containers, if the total memory of all the spaces exceeds the container memory limit, the OS OOM killer will kill the JVM.
• G1 can return unused heap memory from the JVM to the OS since Java 12. Tuning options are G1PeriodicGCInterval and G1PeriodicGCSystemLoadThreshold, 0 disables the features. If more than G1PeriodicGCInterval milliseconds have passed since any previous garbage collection pause and getloadavg() (one-minute) is below G1PeriodicGCSystemLoadThreshold then a full GC or concurrent GC (if G1PeriodicGCInvokesConcurrent is set) is triggered, and at the end of that GC the Java heap size is adjusted and any excess memory is returned to the operation system.
• Several hotspot GC have a -XX:SoftMaxHeapSize=BYTESIZE flag which can be adjusted dynamically to give the ZGC a target heap size (below -Xmx) to try to reach. You can dynamically adjust using "jcmd VM.set_flag SoftMaxHeapSize BYTESIZE" or through the HotSpot MXBean. Note that as well as targeting footprint, this can be used to make the garbage collector more aggressive; The J9 collectors similarly support -Xsoftmx.

Jack Shirazi Back to newsletter 250 contents