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

https://www.youtube.com/watch?v=Gee7QfoY8ys
G1 Garbage Collector Details and Tuning (Page last updated March 2016, Added 2017-09-27, Author Simone Bordet, Publisher Voxxed Days). Tips:

• G1 is intended to be tuned with just two parameters - -Xmx for the maximum heap size and -XX:MaxGCPauseMillis for a target max pause time (default is 250ms)
• Suggested GC logging flags include -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintAdaptiveSizePolicy -XX:+PrintTenuringDistribution
• G1 targets 2048 regions, but you can set the region size with -XX:G1HeapRegionSize
• The four refinement zones (white green yellow red) affect how much work G1 needs to do to update queued pointer changes into the remembered sets. In the white zone, nothing is done (it's drained at the beginning of a GC); in the green zone -XX:G1ConcRefinementGreenZone refinement threads are activated to reduce the queue back to the white zone; in the yellow zone -XX:G1ConcRefinementYellowZone all refinement threads are fully active to reduce the queue; in the red zone -XX:G1ConcRefinementRedZone the application has to update the remembered sets on each pointer change which slows down the application until the queue is back into the yellow zone.
• -XX:+ParallelRefProcEnabled sets G1 to process weak references in parallel (this is recommended), -XX:+PrintReferenceGC gives details on reference processing
• G1 schedules an Old GC when the whole heap is -XX:InitiatingHeapOccupancyPercent full (default 45)
• After an old gen GC is complete, G1 sets a mixed flag, so that after the next young GC, the -XX:G1MixedGCCountTraget fraction (default 8 meaning 1/8th) of old regions which are largely empty are copied to another old region to free up those regions. This is the compacting phase. The regions targeted are those that are more than -XX:G1MixedGCLiveThresholdPercent full of garbage (default 85), and ignores regions with -XX:G1HeapWastePercent garbage (default 5). The mixed flag is turned off when there is enough reclaimed
• G1 full GCs are single-threaded (in Java 8) and very slow, so should be avoided. Use -XX:+PrintAdaptiveSizePolicy to know the reason for the full GC.
• Avoid the "to-space exhausted" situation - your heap needs to be larger.
• Avoid humongous allocations - -XX:+PrintAdaptiveSizePolicy tells you why and -XX:G1HeapRegionSize lets you size the regions larger.

https://dzone.com/articles/what-false-sharing-is-and-how-jvm-prevents-it
What False Sharing Is and How JVM Prevents It (Page last updated July 2017, Added 2017-09-27, Author Artem Rukavytsia, Publisher DZone). Tips:

• Cache coherency during concurrent writing has a potentially high performance cost.
• False sharing is when the memory cells being accessed and updated are different but they fall physically into the same cache line.
• One technique to eliminate false sharing is to pad the memory space between fields used concurrently with intermediate unused fields, so that the actively used fields fall into separate cache lines. Note the JVM can eliminate dead code, so there needs to be some artificial use of padding fields.
• From Java 8, the @Contended annotation will enable the JVM to optimize the fields memory usage to eliminate false sharing, even taking into account prefetching. Use -XX:-RestrictContended to allow classes outside the core Java classes to use this annotation, and -XX:ContendedPaddingWidth to set the padding width to a value different from the default 128. In Java 9, @Contended is not exported by default, so needs explicit module access.

https://stackify.com/java-memory-leaks-solutions/
What to Do About Java Memory Leaks: Tools, Fixes, and More (Page last updated August 2017, Added 2017-09-27, Author Angela Stringfellow, Publisher Stackify). Tips:

• You don't need to worry about all memory leaks, instead factors in the size of the leak and the program's lifetime to see whether the leak is serious enough to need to be fixed.
• Reference objects let you reduce memory leaks and respond to memory pressure, but you can be at the mercy of the garbage collector. They are appropriate for objects like listeners where you need to retain a reference to the listener as long as it is live, but you don't want to hold on to the listener beyond that.
• Classloader leaks are difficult to identify and eliminate. Jetty provides a set of "leak preventer" classes for the most common types of classloader leaks at https://www.eclipse.org/jetty/documentation/9.4.x/preventing-memory-leaks.html
• Closing resources, streams, etc, is an important mechanism for avoiding memory leaks.
• Session leaks are common: release sessions as soon as possible; keep time-outs low; store as little as possible in sessions; don't create HttpSession in your jsp pages.
• The OutOfMemoryError has details in error message that tells you where the problem originates, these details are very helpful in determining where to analyse to find the cause.
• You can use VisualVM to profile memory.
• Heap dumps allow you to see the number of instances open and how much space instances take up.

https://stackify.com/memory-leaks-java/
How Memory Leaks Happen in a Java Application (Page last updated September 2017, Added 2017-09-27, Author Eugen Paraschiv, Publisher Stackify). Tips:

• Memory leaks can occur when objects are no longer being used by the application, but the Garbage Collector is unable to remove them from working memory because they're still being referenced unintentionally.
• Static fields holding on to objects is one common type of memory leak. Pay attention to the lifetime of objects referenced (directly or indirectly) from static fields, especially any collections, these are prime candidates to cause memory leaks.
• Strings interned into the JVM intern memory pool - by calling String.intern() - are potential memory problems, especially before Java 8 when they were stored in Perm Gen.
• Forgetting to close streams is a common type of resource leak. Favour using the try-with-resources syntax wherever possible so that possible routes for unintentionally leaving streams open are minimized.
• A very common memory leak is adding objects to hashed collections where the objects have incorrect equals() and hashCode() implementations.
• TO diagnose memory leaks, use -verbose:gc to monitor memory use, profile using a heap profiler (eg VisualVM), and review your code.

Jack Shirazi Back to newsletter 202 contents