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

?

As I write, Java 10 is due for final release in a few weeks. Java 10 is not a long term support release, the next long term support release is Java 11, due in September. So I'm unsure about what uptake there will be for Java 10. Nevertheless, its useful to see what new performance related features are released with Java 10. The full list is in the news section below. I don't list the most awaited item, local-variable type inference, because that has no effect on performance (just in case you were looking for that in the list). Instead of discussing the individual enhancements here, I've included the feature related discussion with each feature in the news section below.

Now on to that Java 10 performance features news section as well as all our other usual links to articles, tools, talks, blogs. And if you need the tips from this month's articles and talks, as ever they are extracted into this month's tips page.

A note from this newsletter's sponsor

News

Java performance tuning related news.

• JEP 304 Garbage Collector Interface. This is a code cleanup rather than actual delivery of an interface, there will be at least one more JEP to achieve a clean interface. The nice thing here is the stated aim is to support isolated GCs, and specific examples given are so that the community can support CMS when Oracle stops supporting it, and to make Shenandoah (http://openjdk.java.net/jeps/189) easier to integrate
• JEP 307 Parallel Full GC for G1. The worst case pause time for G1 prior to Java 10 is failover into the serial Full GC when the G1 garbage collector just can't keep up with the rate of garbage being produced. Although the G1 goal is for this failure mode to never occur, clearly it does sometimes, so this improvement makes your worst case G1 pause potentially significantly better. So if you are using G1, you really want to move to Java 10
• JEP 310 Application Class-Data Sharing. A new -XX:+UseAppCDS option allows application classes to be shared between JVMs that use the same classpath on the same machine (previously only bootclass loaded classes were shared) - this should allow smaller runtime images and faster startup where it can be used. Note there is a multi-stage procedure. First run with "-Xshare:off -XX:+UseAppCDS -XX:DumpLoadedClassList=somefile.lst" to get the list of classes actually loaded by your application listed into "somefile.lst". Then dump the shared archive using "-Xshare:dump -XX:+UseAppCDS -XX:SharedClassListFile=somefile.lst -XX:SharedArchiveFile=somefile.jsa". Finally you can use the shared archive with "-Xshare:on -XX:+UseAppCDS -XX:SharedArchiveFile=somefile.jsa". Note if the classpath doesn't match the JVM that generated the archive, the JVM will fail to start if you use -Xshare:on. To have it ignore the incompatibility in that case and start normally (no archive used) use -Xshare:auto
• JEP 312 Thread-Local Handshakes. This is an internal improvement to allow improvements to implementations that might benefit from stopping groups of threads instead of all threads. Things that will benefit include G1, biased locking, stack sampling, synchronization. The only relevant item for most developers is that you can disable it with -XX:-ThreadLocalHandshakes
• JEP 316 Heap Allocation on Alternative Memory Devices. Some operating systems already expose non-DRAM memory through the file system. This feature allows the JVM to allocate the heap on those devices using a -XX:AllocateHeapAt=path_to_file_system which will memory map the heap onto the device. All other parts of the JVM runtime remain in DRAM. Note non-DRAM memory is typically slower, so you should understand why you'd want to do this.
• JEP 317 Experimental Java-Based JIT Compiler. To enable Graal to be used as an experimental JIT compiler, starting with the Linux/x64 platform, use -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler. This is the long term future of the JVM JIT compiler, but beware for now it's still experimental

Tools

Java performance tuning related tools.

• (2017) "Troubleshooting Java Performance: Detecting Anti-Patterns with Open Source Tools" By Erik Ostermueller Publisher: Apress
• (2017) "Practical Monitoring: Effective Strategies for the Real World" By Mike Julian Publisher: O'Reilly
• RacerD finds data races in your Java code by statically analyzing using searches for a high-confidence class of data races
• Low-overhead non-blocking I/O replacement for ProcessBuilder Process which reduces memory requirements for interacting with spawned processes

Articles

• Scalability Is Quantifiable: The Universal Scalability Law (Baron Schwartz/Usenix)
• Fast and Safe Production Monitoring of JVM Applications with BPF Magic (Sasha Goldshtein/Usenix)
• Collections.compare:JDK, Eclipse, Guava, Apache (Leonardo Lima/JavaOne)
• Chapter 1 of Practical Monitoring (Mike Julian/O'Reilly)

Jack Shirazi

Back to newsletter 207 contents