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

Java 13 is released in less than a month. As usual I'm listing all the new performance features in the release, just as I now do every 6 months with each new Java version. The new features, the performance benefits from each feature, and how to use the feature.

Of the new performance features released in Java 13, JEP 353: "Reimplement the Legacy Socket API" is one that you need to plan extensive testing for. Although intended to be a nearly totally transparent drop-in replacement of the existing Socket implementation, they point out that edge cases will behave differently. That sounds innocuous, but my experience of applications using network IO in any intensive way is that edge cases abound, with lots of code dependent on particular behaviour that's been encountered and specially handled.

On the plus side, timeouts on sockets were always a little unreliable, and with the new implementation they should be much more reliable. Now on with details of those Java 13 changes, including the options you have available to use them, relevant tools and articles, and of course all the useful performance tips in from those articles extracted into this month's tips page.

A note from this newsletter's sponsor

News

Java performance tuning related news.

• A new implementation for TCP sockets in the JVM (needed for integrating fibers properly). The old implementation remains available, and can be switched on by setting the property jdk.net.usePlainSocketImpl to true (or apparently anything, though presumably not to false). You need to test the change if you rely on TCP IO behaviour. Also note that java.net.SocketInputStream and java.net.SocketOutputStream are no longer used in the new implementation, which may affect any instrumenting monitoring tools
• ZGC now returns unused heap memory to the operating system. The flag -XX:ZUncommitDelay=SECONDS (defaulted to 5 minutes, ie 5*60 seconds, same as -XX:ShenandoahUncommitDelay=) let's you set the timeout after which unused memory is returned, and the flag -XX:-ZUncommit allows you to turn off the capability. In all cases, memory will never reduce below the -Xms value
• Application class data sharing (allows multiple JVM processes to share classes which reduces startup time and footprint) now allows the dynamic archiving of classes at the end of Java application execution, by adding the flag -XX:ArchiveClassesAtExit=FILEPATH. The class data archive will be dumped on normal exit of the JVM (not on a crash). All the existing class data sharing capabilities still work, this is an additional option. The previous procedure was to: 1. Do one or more trial runs to create a class list; 2. Dump an archive using the created class list; 3.Run with that archive. Now you can dump with "bin/java -XX:ArchiveClassesAtExit=FILEPATH ..." and run with "bin/java -XX:SharedArchiveFile=FILEPATH ...". Classes that are not loaded will not get dumped, so bear that in mind if you have instances that run through different code pathways
• A new -XX:SoftMaxHeapSize=BYTESIZE flag which can be adjusted dynamically gives 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
• ZGC maximum Heap Size has been increased to 16TB (was previously 4TB)
• The deprecated -XX:+AggressiveOpts flag has been removed (only edge case GC tuners ever used it)
• The obsolete methods traceInstructions(boolean) and traceMethodCalls(boolean) have been removed from the java.lang.Runtime class. These methods have been non-functional for many releases. Did you ever try them? Never worked for me anyway
• Improved the behavior of MaxRAM settings with UseCompressedOops - prior to this change, if the heap size selection resulting from various these flags exceeded the maximum reachable address when UseCompressedOops is enabled, the heap size would be truncated to be within the CompressedOops range. Also, the percentage or fractional calculation performed was based on the value of MaxRAM and not the amount of physical memory available in the system. The following are the options impacted by this change: -XX:MaxRAMPercentage -XX:MaxRAMFraction -XX:MinRAMPercentage -XX:MinRAMFraction -XX:InitialRAMPercentage -XX:InitialRAMFraction -XX:MaxRAM. The new behavior calculates the percentage or fraction based on the host's available memory unless the user also specifies -XX:MaxRAM. In addition, UseCompressedOops is automatically disabled if the heap size resulting from the use of any of these options, including -XX:MaxRAM, is greater than can be addressed in CompressedOops mode, unless the -XX:+UseCompressedOops option is specified to override this behavior

Tools

Java performance tuning related tools.

• ZGC main tool page
• Documentation for -XX:SharedArchiveConfigFile=FILEPATH option
• cl4cds tool to help create Application Class Data Sharing classlist files for the -XX:SharedClassListFile option

Articles

• Improve Startup Performance and Reduce Footprint with Application Class Data Sharing (Jiangli Zhou, Ioi Lam/Oracle)
• Class Data Sharing in the HotSpot VM (Volker Simonis/JavaZone)
• ZGC: A Scalable Low-Latency Garbage Collector (Per Liden/Oracle)

Jack Shirazi

Back to newsletter 225 contents