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

As usual before a Java release, I'm listing all the new performance features in the upcoming release, this time for Java 26 (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). In each of these pre-release newsletters, I give the new features, the performance benefits from each feature, and how to use the feature. If you want to see the full list of performance features for any version, they are conveniently listed together in my page showing all the performance changes in each release of the JVM since Java/JDK/JVM 10.

There aren't any standout performance features in this release, though the availability of HTTP/3 is interesting (it's UDP based, and in most situations it's faster and higher throughput than HTTP/2, including faster connections). A minor new feature is that Process now implements AutoCloseable - I explain the possible improved reliability in this article

Java 26 is a non-LTS release, so will only be supported for 6 months. Now on to the details of those Java 26 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 26 performance changes

• JEP-500: Prepare to make final mean final. You'll get warnings now if any final fields are mutated. In some future release you'll need to explicitly enable it if you want to allow that
• JEP-516: Ahead-of-time object caching with any GC. You can explicitly create a cache whose objects are in the streamable, GC-agnostic format by specifying -XX:+AOTStreamableObjects. Can improve startup time for some apps
• JEP-517: HTTP/3 for the HTTP Client API. HTTP/3 is based on UDP so potentially a very different performance profile under network load. In most situations it's faster and higher throughput than HTTP/2, including faster connections
• JEP-522: G1 GC: Improve throughput by reducing synchronization. Nothing to explicitly change, but if you upgrade you get better G1 throughput for some apps. Disable with -XX:-G1UseConcRefinement or limit the threads with -XX:G1ConcRefinementThreads=NUMBER_OF_THREADS
• Virtual threads now unmount from the carrier when waiting for another thread to execute a Class initializer. This is a performance improvement and deadlock prevention in some edge cases
• java.lang.Process implements AutoCloseable and Closeable. Process has a new close() method and supports AutoCloseable. Closing a process ensures that it has terminated and its streams and underlying resources are released. When used with try-with-resources, the process and its streams are closed when the try-with-resources block exits
• A new static ofFileChannel(FileChannel channel, long offset, long length) method has been added to java.net.HttpRequest.BodyPublishers to upload a region of a File. The new publisher can be leveraged to implement sliced uploads
• A new MemoryPoolMXBean.getTotalGcCpuTime() method has been added that returns the accumulated CPU time in nanoseconds for GC related activity
• G1 supports UseGCOverheadLimit. G1 now throws an OutOfMemoryException when the garbage collection overhead is more than GCTimeLimit percent (default value 98) and the free Java heap is less than GCHeapFreeLimit percent (default value 2) for five consecutive garbage collections. This can be disabled using the -XX:-UseGCOverheadLimit option
• G1 now eagerly reclaims eligible humongous (very large objects that occupy more than half a heap region) objects containing references. Instead of requiring liveness analysis (concurrent marking) of the entire Java heap, G1 can collect these objects at any garbage collection pause if they are not referenced any more
• The thread dump generated by the com.sun.management.HotSpotDiagnosticMXBean.dumpThreads API, and the diagnostic command jcmd <pid> Thread.dump_to_file, now includes information about park blocker owner for threads that are blocked for parking on java.util.concurrent.locks.AbstractOwnableSynchronizer objects
• Thread.stop has been removed
• The AlwaysActAsServerClassMachine and NeverActAsServerClassMachine Flags have been deprecated. These are used to influence two separate behaviors: 1) which GC is chosen by default, and 2) to influence whether client emulation mode is selected. Users should instead explicitly configure the GC they want, for example by using -XX:+UseSerialGC or -XX:+UseG1GC
• the AggressiveHeap flag has been deprecated. Users who require their application to continue with similar behavior should specify the corresponding flags: -XX:+UseParallelGC -XX:+UseLargePages -XX:-ResizeTLAB -XX:TLABSize=256K -XX:YoungPLABSize=256K -XX:OldPLABSize=8K -XX:ThresholdTolerance=100 and set the following values: -Xmx and -Xms to half the available physical memory -XX:NewSize to 3/8 of available physical memory -XX:MaxNewSize to the value of -XX:NewSize
• The C2 JIT compiler can now compile Java methods with a large number of parameters - previously C2 would fall back to C1-compiled code or the interpreter
• G1 can again properly utilize Transparent Huge Pages (THP) on systems with the THP mode configured as madvise - there was previously a bug preventing the option -XX:+UseTransparentHugePages from enabling THP
• The default initial heap size is now set to MinHeapSize which is the minimum possible heap size. Previously if users did not specify the initial Java heap size using -Xms or -XX:InitialHeapSize, the Java Virtual Machine's (JVM) memory management decides the initial Java heap size using the InitialRAMPercentage setting. The default has been 1/64 of the system's physical RAM. This behavior resulted in large initial Java heap sizes on modern systems with a substantial amount of memory, increasing JVM startup times due to necessary initialization of Java heap-related internal data structures. To get the previous behavior, users can explicitly set InitialRAMPercentage to the original value of 1.5625, or configure the initial Java heap size directly using the -Xms or -XX:InitialHeapSize options
• JEP-525: Structured Concurrency (Sixth Preview). Simplify concurrent programming by grouping related tasks running in different threads
• JEP-526: Lazy Constants (Second Preview). An API for lazy constants, objects that hold unmodifiable data. Treated as constants by the JVM, enabling the same performance optimizations that are available by declaring a field final
• JEP-529: Vector API (Eleventh Incubator). Vector computations that reliably compile at runtime to optimal vector hardware instructions. Useful for ML, GenAI, image processing, scientific processing, massive financial calculations, etc
• JEP-530: Primitive types in patterns, instanceof, and switch (Fourth Preview). Unlikely to provide any significant performance improvement (fair enough as that's not the motivation)

Tools

Java performance tuning related tools

• HTTP/3: var client = HttpClient.newBuilder().version(HttpClient.Version.HTTP_3).build();
• Java 26 Process AutoCloseable: Cleaner Process Execution

Articles

• LazyConstants in JDK 26 (Nicolai Parlog/Inside Java Newscast)

Jack Shirazi

Back to newsletter 303 contents