How does a made-for-JVM Linux distro perform? Alpaquita Linux benchmarks are imp...

1. The first details of JDK 20

The time is rushing by - we've only celebrated JDK 19 and the JDK 20 is already underway. To remind us about its imminent release, an official schedule was published last week, with dates of the paritcular planned releases:

• 2022/12/08 Rampdown Phase One

• 2023/01/19 Rampdown Phase Two

• 2023/02/09 Initial Release Candidate

• 2023/02/23 Final Release Candidate

• 2023/03/21 General Availability

So as we can see, on December 8 (Rampdown Phase One) we'll find out what things will fly into the new release and what we'll be able to enjoy back in March. Such a bit of a late Santa Claus present.

Just in time as a counterweight to what is happening in the world of commerce

Well, but what can be expected in a given release? So far we don't know much yet, and the JDK developers are revealing their cards extremely slowly. However, there are currently three JEP previews in the queue, which are another increment over the functionalities already presented.

So first, JEP 432: Record Patterns (Second Preview). This is a continuation of the work on Pattern Matching in Java and it presents as follows:

record Point(int x, int y) {}

static void printSum(Object obj) {
    if (obj instanceof Point p) {
        int x = p.x();
        int y = p.y();
        System.out.println(x+y);
    }
}

I got an interesting question recently - what do Records really give us when basically the same capabilities can be obtained by adding Lombok to the project? There are people who point to Lombok's code generation itself as too much "magic" that they would like to get rid of from the project. However, given how many other "magic" mechanisms we have in the ecosystem, this is rather petty. Much more important is the fact that on top of the records once built, developers, can add more feats like the described JEP 432. Lombok, not being part of the language, for obvious reasons does not allow anything added to the JDK to be based on it. That's why standardizing its various functionalities is so important.

Okay, but let's get back to the substance. Continuing with Pattern Matching, JEP 433 is the fourth preview Pattern Matching for switch. The changes are actually quite cosmetic, and the most important from my perspective is the addition of MatchException, thrown in case none of the possible cases are matched, thus ensuring the "exhaustibility" of switches.

But to find it, this is how I read the new Preview....

The last of the recently published JEPs, meanwhile, is the second preview of Foreign Function & Memory API. Here, finding changes is easier - as the MemoryAddress and MemorySegment abstractions have been unified, and care has been taken to make the latter more useful in the context of Pattern Matching.

That's it for now for new JEPs to expect in the next JDK. However, it is likely that it will also come with...

Sources

2. ZGC becomes Generational

There was a time when practically every new JDK release brought some significant changes to existing Garbage Collectors, or even the appearance of new ones. However, it's apparent that this topic has become a bit standstill - admittedly, just some minor tweaks are still being made on the subject. Recently, however, there has been an early version of an interesting iteration over ZGC Garbage Collector, with the graceful name Generational ZGC.

In Garbage Collector theory, there is such a concept as the Generation Hypothesis. In simple terms, it is the observation that in practice most objects are very quickly suitable for collecting. In turn, those that survive a certain period of time are quite likely to live for a long time to come. Most Java Garbage Collectors are designed with this very principle in mind.

The exception here is ZGC - a modern Garbage Collector, which is used to clean up even terabytes of memory without an interruption of more than a few milliseconds. ZGC is referred to as a low-latency GC, and can be considered a kind of state-of-the-art when it comes to the JVM. However, it is not without flaws - the greatest is the fact that ZGC's design is very complicated. This caused its first (current) version to be single-generation, as a result of which the solution has always had a problem with the so-called "purification of the young generation", i.e. precisely those short-lived objects. However, the developers announced from the very beginning that they would not stop there and intended to add generations in a later time - one can cite talk ZGC: The Next Generation Low-Latency Garbage Collector, presented during Oracle Developers Live in 2020. Now, finally, an Early Access version of it has come into our hands. I haven't found any news on whether the whole thing will make its way to JDK 20, but I'm hoping that we might get at least a Preview version there.

The topic of Generational ZGC didn't take us by surprise - I first had a chance to hear about it back in June, in a podcast inside.java - Episode 24 - "Towards Generational ZGC!". If you want to learn more, I recommend it, especially since the episode is very "to-the-point" and only 15 minutes long.

Sources

3. BellSoft has created a Linux distribution specialized for Java containers

BellSoft is one of the most respected JDK vendors, creating Liberica JDK - the most "free" of all JDK versions. They are therefore one of the most important providers of a runtime platform for Java applications. However, in 2022, Java Developer Kit is just one of the important building blocks. Today, more and more applications are packaged in containers, in which they are deployed to all sorts of clouds or Kubernetes clusters. Consequently, the underlying base image of the container in which our Jar is run can have as much impact on the performance and security of the application as the JDK distribution.

Software Development, 2022

BellSoft seems to have noticed this too and decided to create a new reference Linux distribution designed directly to run Java in containers. At first glance, it sounds a bit like shooting a cannon at a fly, but there is a method in the madness. The creators have taken minimalist Alpine, which itself adds really minimal overhead (I've used it in practice, and it's almost unnoticeable), but modified it in a way that is supposed to provide, in the case of JVM applications, much better security and performance. BellSoft e.g. created a modified variant of the musl memory allocator, also used by Alpine, and which support was added quite recently in JDK 16. They named the whole thing Alpaquita Linux, added LTS support, and packaged it together with the previously mentioned Liberica JDK. They've published some numbers and benchmarks to back up their version that they've succeeded in creating the best customized Linux distribution for containerized Java.

PS: If you are curious about the history of Liberica JDK - recently Adam Bien in his podcast AirHacks.fm had an interesting conversation on the subject with Dmitry Chuyko - Performance Architect at Bellsoft, who also is the author of the above benchmarks.

I know, a lot of these podcasts today, but more and more interesting content in the Java world is emerging in the audio format.

Sources