JVM

Is there a “greenest” JVM? Spoiler: as usual, it depends – JVM Weekly vol. 170

Today we don’t have many news items, but rather longer publications that describe individual topics in more depth. I hope this will be a pleasant change from the flood of releases.

Article cover

1. How to easily use Visual Studio Code with Java, straight from JDConf 2024

Let’s start on the conference front. For last week we had a big, strictly Java-based online conference from Microsoft. JDConf 2024, for that’s what it was called, had four different tracks (for three different time zones), in which Microsoft managed to pack a very good line-up of presenters that covered pretty much all the topics the Java community lives by in 2024.

Here you have the European path for those interested, you can find the rest at the link.

So there was news in Spring, Virtual Threads, CRaC, AI/LLMs (including Microsoft’s Semantic Kernel, which I personally use and actually recommend even though it’s still a de facto test version of the project), the cloud and even the Valhalla project. I’m only just making my way through the various topics presented myself (after all, it’s more than half a day’s worth of material in total), but there is one talk that I already wanted to share with you.

For her session From Zero to Java Hero: Visual Studio Code Mastery, Loiane Gorner shared her experiences of using Visual Studio Code to develop Java code. From a certain point of view, this was the most practical of all the presentations, because while we often have no control over the technology ship we use (compromises, compromises everywhere), the IDE / Editor we use (usually) remains a certain oasis of freedom and a manifestation of a certain individualism. And since I like Visual Studio Code very much myself, and very rarely devote space to it this topic  – where it usually gives way to IntelliJ Idea, however – I found today that it was worth giving it some love and “airtime”.

Additionally, I was captivated by a certain ‘multimedia’ quality of Loiane’s publication, which, in addition to the talk, in recent weeks has published Visual Studio Code for Java: The Complete Guide (Tips, Setup, and Extensions) telling how to work with VSCode in Java projects. The article smoothly introduces the necessary steps, setup and add-ons for VSCode, the author recommends starting with the Coding Pack for Java, which combines VSCode, the JDK and the necessary extensions to simplify the initial setup process. The guide describes the various features, from the completely basic to the advanced, including JDK version management or testing and debugging tools, and the use of extensions for project management, code analysis or application security. Java alone is not the end of the story – Loiane also describes sample configuration for Spring, support for microservices or integration with Docker.

And to wrap up the Visual Studio Code theme, February saw the release of a sizable update for the official extension for Java from Oracle. It includes support for new features from the newly released JDK 22, as well as the introduction of a context menu option to run any project and added support for using different JDKs in each workspace, moving away from the now deprecated jdk.userdir configuration. Improvements also include the inclusion of TestNG tests in the test explorer, a ‘Go to test’ feature, and a new configuration for user-defined VM arguments to run the Java server.

Discover more IT content selected for you
In Vived, you will find articles handpicked by devs. Download the app and read the good stuff!

phone newsletter image

2. Is any of the JVMs the most “green”?

All sorts of emissions reduction and sustainability are issues that have been increasingly discussed in recent years. Personally, I like them a lot, because it’s one of the more interesting business (aside from the obvious cost-optimisation) topics to argue for writing more efficient, better-scaling applications. Suddenly, the industry rule of thumb “programmers’ time is more valuable than servers’ time” may no longer apply if we also take into account environmental costs. On the other hand, it is important not to get too crazy and to approach the topic head-on, reaching for the lowest hanging fruit first, rather than doing the classic “premature optimisation” – because the original quote was more or less about optimising the algorithm first, rather than doing black magic on the CPU registers, but quite possibly also looking for the “right” JVM implementation. Is there any difference between the different JVM variants in terms of power consumption? Fortunately, someone has checked and compared this for us in engineering terms.

To avoid falling into the trap of flashy headlines. PS: “Real ones” also exist.

Ionuta Balosin, whom you may associate with his experiments on JVM performance, this time decided to pick different topic and, in the publication Analyzing JVM Energy Consumption for JDK 21: An Empirical Study, carefully examine the energy consumption patterns of different JVMs. To do this, he used command lines such as powerstat and powermetrics, and physical measuring devices (such as plug-in power meters) to gather the most realistic energy consumption data possible. These tools allow the performance of the JVM to be assessed on different architectures, as powerstat offers insight into power consumption via Intel’s Running Average Power Limit (RAPL) interface on GNU/Linux systems, and powermetrics performs a similar function on macOS for ARM64 architectures. RAPL is particularly important because of its detailed reporting of power consumption of various components, such as CPU and DRAM, in a granular way, although even this does not cover all system components, such as network interfaces or storage devices.

Interestingly, the text does not mention Windows for a second.

In his experiments, Balosin conducted tests on a range of applications, from well-known demo-projects such as Spring PetClinic and Quarkus Hibernate ORM Panache, to custom applications that allowed for the investigation of specific coding patterns and their impact on energy consumption, such as particular memory access methods, logging practices, exception handling mechanisms, string concatenation methods and sorting algorithms of varying complexity. Each JVM was tested under controlled conditions to ensure a fair comparison, with consideration given to minimising external variables that could distort the measurements, such as ensuring the JVM was appropriately loaded.

The results of the study are not revolutionary, but nevertheless contain some interesting observations. For example, Oracle’s GraalVM Native Image, especially when optimised behind PGO (Profile-Guided Optimisation), showed a favourable balance between energy efficiency and performance, highlighting the potential benefits of Ahead-of-Time Compilation to reduce energy consumption at runtime. However, of course, there are two ends to every stick – this involved higher energy consumption on the build process, and as the difference was not particularly noticeable, achieving maximum energy efficiency requires appropriate… prioritisation. Furthermore, the study highlighted the complexity of the relationship between energy consumption and performance in different JVMs and application types, due to the huge number of moving parts. This makes it difficult to draw broad conclusions about energy efficiency, as the most energy-efficient JVM in one scenario may not hold that title under different conditions or with different types of applications. The conclusions are therefore … well there aren’t many, but the experiment itself is mega interesting and I personally love Ionut’s remarkable insight.

And if the topic appealed to you, I will admit that (as I mentioned at the beginning) I myself have fallen down the rabbit hole of all sorts of sustainability-related topics this year. That’s why I have some supplementary readings for you, which I myself found particularly interesting, but which also highlight how complex the issue they address is.

Recommend if you want to get a better feel for the theme. Enough paperbacks for us to be able to do our own little ‘Papers We Love’ like this. It’s also the result of my research, which I needed for a new talkie The State of the Green IT at the beginning of 2024 (spoiler – I’ll have a chance to present it at JUG Copenhagen in May, I’ll probably let you know). The whole thing also partly overlaps with the text What is Green IT – Strategies and trends lined out, which I had a chance to scrap once.

The last thing I wanted to recommend to those who would like to check the energy efficiency of their applications is JoularX, which is a Java Agent just for measuring energy, including a breakdown of the various methods. I’ve used it myself in projects for clients wishing to comply with the CSRD regulation coming into force this year (although I’ll admit it’s mainly by special request, contrary to what people think of it the European Union is unlikely to benchmark your code) and it’s convenient to use, although analysing the data itself requires a bit of patience.

PS: If you have this type of challenge and would like to chat about how it can be approached, I would very love to pop in for a coffee. This is a really interesting topic.

PS2: And finally, I classically recommend the book “Not the End of the World” to help you not go crazy in the deluge of headlines mentioned above. The most talked-about item on the subject lately, it’s very coolly nuanced when it comes to stats selection.
Discover more IT content selected for you
In Vived, you will find articles handpicked by devs. Download the app and read the good stuff!

phone newsletter image

3. CRaC: A detailed tutorial from AWS and support in Alpaquita Linux

A last, a bit overdue text that nevertheless fits in very well with my area of interest is the March publication from AWS, where the cloud provider describes how to use CRaC to provide a more ‘cloud-native’ user experience for Java applications. What Project CRaC is I’ve mentioned a number of times (for those new to it, I’d recommend one of the previous editions), but in sum we’re talking about an overlay on top of the Linux CRIU (Checkpoint/Restore In Userspace) mechanism, which allows you to dump an entire process to your hard drive so that you’re then able to launch it from the checkpoint so saved. In the publication Using CRaC to reduce Java startup times on Amazon EKS, AWS presents detailed instructions on how to go through the entire process, and on all layers – the cloud itself (including, for example, IAM and container registry), through Kubernetes, Docker, ending with the integration of the mechanism in the application. This is probably the first such cross-cutting tutorial I’ve come across, and what’s probably a bit intimidating is how many consecutive steps and moving parts are necessary to be able to get the expected gains, however. The result is definitely worth it – going from 12 seconds to under a second is definitely something that in many cases (ekh ekh – auto-scaling) motivates you to go through it.

Slightly amusing, meanwhile, is the fact that the article scrolls through not Amazon’s own JDK distribution, Corretto, but Zulu from Azul.

This only serves as a reminder of the fact that, however, CRaC is not an official part of OpenJDK, but only an optional add-on. Therefore, it is really only supported at the moment by Zulu and Liberica from BellSoft.

Interestingly, it is the latter company that has decided to simplify life for all potential CRaCa users. As I mentioned, the manual from Amazon is long and complicated, so the engineers at BellSoft decided to make the whole process a little simpler for us. This is because, in addition to its own JDK variant, the company also creates its own Alpine-based Linux distribution called Alpaquita, specifically profiled for use with Java. This one is also available in the form of ready containers, including, as of now, such with a pre-configured CRaC. Of course, this only simplifies some of the challenges of reading the AWS text, but it seems worth trying Liberici if you are looking for an easy entry into the world of CRaC.

This joke will never get old.