Java Performance Tuning
Java(TM) - see bottom of page
Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks!
Training online: Concurrency, Threading, GC, Advanced Java and more ...
News February 2018
JProfiler
|
Get rid of your performance problems and memory leaks!
|
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
JProfiler
Get rid of your performance problems and memory leaks!
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.
Articles
Jack Shirazi
Back to newsletter 207 contents
Last Updated: 2024-11-29
Copyright © 2000-2024 Fasterj.com. All Rights Reserved.
All trademarks and registered trademarks appearing on JavaPerformanceTuning.com are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. JavaPerformanceTuning.com is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
URL: http://www.JavaPerformanceTuning.com/news/news207.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us