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

As usual just before each Java release, I'm listing all the new performance features in the upcoming release, this time of Java 18 (I have done this every 6 months prior to each new release, you can track back to the previous February and August newsletters if you want to see what's new performance-wise in any particular release). Each time I give the new features, the performance benefits from each feature, and how to use the feature.

Java 18 is very light on performance changes. I found this surprising. Java 17 was a Long Term Support (LTS) release, and no one wanted to make a significant change in that release because it is supported for a long time, so all the significant changes had been in earlier releases. I expected that meant there was a backlog of changes that would go into Java 18. But not much has turned up.

Perhaps the most significant performance change in Java 18 is JEP 421: Deprecate Finalization for Removal. Not so much for the actual deprecation, but for the detailed contents of the JEP itself - it's a very clear well written coverage of all the things that are wrong with using finalize() and the alternatives available to you. If you are an advanced Java developer, you should read it.

Now on to the details of those Java 18 changes, including the options you have available to use them. And of course the tips from this month's articles, as ever are extracted into this month's tips page.

A note from this newsletter's sponsor

News

Java performance tuning related news - Java 18 performance changes

• Reimplement Core Reflection with Method Handles. Mainly a maintenance change, but there could be performance impact (either way, ie slightly faster or slower depending on the code). A new jdk.reflect.useDirectMethodHandle property allows the old implementation to be used for now
• Vector API (Third Incubator). Vector computations that reliably compile at runtime to optimal vector hardware instructions. If you use these types of operations - eg ML, image processing, scientific processing, massive financial calculations, etc - then you should check it out and feedback since this matters to you
• Internet-Address Resolution SPI. Let InetAddress use plug-in implementations for DNS lookups. Although not delivered with this JEP, a non-blocking SPI should be available soon
• Foreign Function & Memory API (Second Incubator). Still in incubation after many iterations. Useful for off heap management
• Deprecate Finalization for Removal. Important in that if you are still using finalize(), you'll need to make code changes at some point in the next 5 years. Also well worth reading for understanding finalize() disadvantages and the alternatives recommended
• Terminally deprecate Thread.stop(). It's been deprecated for ages because it was unsafe. While it was unsafe, it was always potentially useful. But actually it never worked consistently, there were all sorts of situations when a thread would fail to stop anyway. So for performance practitioners this is more a reminder that if you need control over rogue threads, you don't really have an option other than to spawn a process which can be reliably killed
• GC accidentally cleans valid megamorphic vtable inline caches. Fixed long Process Non-Strong References times. This performance bug is fixed, reported against ZGC but potentially affects multiple GC implementations
• Configurable card table card size. A new option -XX:GCCardSizeInBytes sets size of the area that a card table entry covers (previously fixed at 512 bytes, now that's the default). Permissible values are now 128, 256, and 512 bytes for all platforms, and 1024 bytes for 64 bit platforms only. Smaller card sizes can lead to less work during garbage collection (which can speed up GC) but lead to more memory usage (which in turn can slow GC)
• Virtualize G1CardSet containers over heap region. Extends the maximum allowed heap region size from 32MB to 512MB for the G1 garbage collector. The default ergonomic heap region size selection is still limited to 32MB regions maximum, sizes beyond that must be selected manually by using the -XX:G1HeapRegionSize command line option. This can mitigate fragmentation issues with large objects on large heaps. On very large heaps, using a larger heap region size may also decrease internal region management overhead and increase performance due to larger local allocation buffers
• Add a finalization JFR event. A new JDK Flight Recorder Event, jdk.FinalizerStatistics, identifies classes at runtime that use finalizers. The event is enabled by default in the JDK (in the default.jfc and profile.jfc JFR configuration files). When enabled, JFR will emit a jdk.FinalizerStatistics event for each instantiated class with a non-empty finalize() method. The event includes: the class that overrides finalize(), that class's CodeSource, the number of times the class's finalizer has run, and the number of objects still on the heap (not yet finalized)
• Extended Delay Before JDK Executable Installer Starts From Network Drive. On Windows 11 and Windows Server 2022, there can be some slowness with the extraction of temporary installation files when launched from a mapped network drive

Tools

Java performance tuning related tools

• Cleaner class
• Approaches to using Cleaner

Articles

• The final days of finalizers in Java (Andriy Redko/aredko)

Jack Shirazi

Back to newsletter 255 contents