LZ4 new release:
v1.11.0 introduces multithreading in the library, and substantial speed gains for small data.
And more tests. Tons of little tests and minor fixes following a large influx of contributions.
This is a recommended upgrade:
github.com/lz4/lz4/releas…

The #rust compiler is getting tons of improvements this year yoyo-code.com/2026-is-exciti…

JEP 544 (openjdk.org/jeps/544), the remaining part of Leyden has landed in JDK mainline. So now we can do this! This source launcher involves javac compilation, that is the bulk of the work here.

You can consume compressed JSON documents in a multithreaded manner if you use zstd for compression. This allows crazy speeds. See my article.

Performance Improvements in JDK 27

inside.java/2026/09/28/per…

Meta Releases OpenZL 0.3 With Decompression Speed 144% Faster Than Zstd

Wow!

phoronix.com/news/OpenZL-0.…

OpenZL v0.3.0 is released :
github.com/facebook/openz…

It has a faster LZ engine, close to LZ4 speeds, featuring a novel Huffman backend (PivCo), and a neural network that builds compression graphs on the fly, resulting in much higher compression ratios for numeric sources.

✅ JDK 27 shipped yesterday with Shenandoah Late Barrier Expansion (JDK-8366041), gets us 0..20% throughput bump.
🔄 JDK 28 would hopefully ship in Mar 2027 with Shenandoah Hotpatching (JDK-8384415), gets us another 0..5% throughput bump.
🤘 JDK 29 in Sep 2027 would be awesome.

If you like the compact 64-bit object headers of HotSpot in Java 27, you will love the 32-bit object headers in @graalvm native image that are the default since Java 25 😉!

"To evaluate the warmup benefit of AOT code, we ran a javac benchmark application which repeatedly compiles the same 50 source files... The AOT cache without AOT code improves startup time by about 30%; adding AOT code brings an additional 45% improvement, for a total of 75%"

"We here propose to finalize Structured Concurrency in JDK 28, without further change" openjdk.org/jeps/543

The Rust team is calling this the largest single change to the compiler since its initial release. It just landed on nightly. 🦀

After nearly 4 years of work, the next-generation trait solver is close to stabilization. It completely replaces how rustc proves where-clauses, ypes, and reasons about generics : the deep internals most Rust code depends on without ever seeing directly.

Why it matters, concretely:
→ More than 200 known GitHub issues fixed by this change alone
→ Unblocks Type Alias Impl Trait and Return Type Notation, both stuck behind this for years
→ Opens the door to fixing remaining type system unsoundnesses
→ Fixes real bugs found in production crates like bevy and minijinja

The performance story is the most interesting part. The new solver was, in some cases, quadratically or exponentially slower than the old one. The team benchmarked the top 20,000 crates on crates.io and spent the last few weeks specifically hunting down the worst outliers.

The results are already dramatic in places: datafusion now compiles over 8x faster. A chess engine implemented entirely in Rust's type system, which used to hang the old solver completely, now compiles in about a minute.

Still nightly-only, still finding edge cases and rough error messages. But four years of foundational compiler work, tested against real-world code at genuine scale, heading toward stabilization in the coming months.

🔗 blog.rust-lang.org/2026/08/21/ena…

#RustLang #CompilerEngineering #TypeSystems

> Co-authored-by: Aleksey Shipilev <shade@openjdk.org>

Happy to be a part of it. Now onto stabilizing the whole thing in time for JDK 28 and 29 (prospective LTS) to be released. This and lots of other goodness should make JDK 29 a very compelling migration target. Prepare now!

JEP 401: Value Objects (Preview) merged to OpenJDK master (64 co-authors)

Commit: github.com/openjdk/jdk/co…

"At the reported irregular widths, the explicit vector kernel reaches approximately 4.7 times the throughput of the generic scalar decoder. Against the regular width-8 widening loop, the advantage falls to approximately 1.3 to 1.65 times"

The following time to peak performance analysis on constrained containers uncovered an interesting AOT Code Compilation peak perf bug.

redhatperf.github.io/post/when-the-…

"Goetz added JEP 401 will still likely be in preview in the next LTS release of the JDK. "Hoping for it to exit preview for 29 seems … optimistic."
share.google/hUxe4oXCK4Monh…

Nice wins from Shenandoah late barrier expansion "Our expectation was that LBE would be most impactful on C2 compilation times. We are indeed seeing up to 30% faster compilations. However, LBE also dramatically improves application performance directly."