Eclipse OpenJ9 v0.42 Released With OpenJDK 21 Java Support

[phoronix]

Phoronix: Eclipse OpenJ9 v0.42 Released With OpenJDK 21 Java Support

Eclipse OpenJ9 v0.42 released this week as the high performance Java Virtual Machine spun out from the IBM J9 JVM...

https://www.phoronix.com/news/Eclipse-OpenJ9-0.42

[bug77]

Once again Michael copies the "high-performance" claim verbatim from the product page, once again I remind him there's no evidence for OpenJ9 being faster overall than other JVMs.

On top of that, being "high-performance" is even less important for a JVM, since the native-image seems to be production ready (or close to that).

On a more positive note, I guess it deserves some praise for not lagging too much behind OpenJDK 21. There are a few worthwhile additions in there, even if virtual threads support still needs some changes that are currently in preview state.

[darkonix]

I'm curious if anybody is using J9 and why.

[bug77]

I'm curious if anybody is using J9 and why.

I'm a Java developer and I never heard of anyone using it. It's a former IBM project, so maybe they are using it. IBM loves to use in-house reimplementations of everything. On the other hand, they tend to open source stuff only when they don't feel like maintaining it anymore, so I really don't know.

[spicfoo]

I'm a Java developer and I never heard of anyone using it. It's a former IBM project, so maybe they are using it. IBM loves to use in-house reimplementations of everything. On the other hand, they tend to open source stuff only when they don't feel like maintaining it anymore, so I really don't know.

You do know that IBM helped create the Apache and Eclipse software foundation and is a major contributor to both and contributed so funding to the tune of billions in the late 90's and core code to Linux that they were accused of ripping of Unix and had to fight a major lawsuit from "SCO" for years? It's a large company, sometimes they throw code over the wall and sometimes they are key contributors. It depends on the project.

[spicfoo]

I'm curious if anybody is using J9 and why.

One of the organizations I am consulting with uses it with Apache OpenWhisk where apparently it has better resource utilization/performance for how they are using it. I am not involved in that effort however so don't have any direct experience with it.

[Mangogeddon]

We're using it, and have been since whenever JDK 13/14 were current. At the time it had much better resource handling around running in a container, it had more aggressive behavior around de-committing memory back to the OS (it has heuristics around detecting when an application is idle in order to pro-actively run GC cycles). We saw a substantial decrease in memory consumption per-pod when we switched to it, which allowed us to increase density on our Kubernetes nodes by a fair bit.

Additionally the runtime takes a more opinionated approach to auto-configuration of the JVM. There's an expection around running Hotspot that if you want to optimize it that you'll need to get your hands dirty with modifying the various configuration knobs. This is less true with OpenJ9, it's more so that you choose a specific "profile" (though it does a good job choosing one automatically depending on available resources) and then it will try to dynamically adjust certain values as behavior changes. This has led to less Ops time spent trying to optimize the JVM while still retaining good performance.

There are some other benefits as well:
- The Shared Classes Cache feature is really nice. Basically the JVM can be configured to persist compiled JIT and AOT code to disk. This cache can be read by multiple running JVMs at the same time (so code compilation only needs to happen once) which can dramatically reduce startup time and resource use (since the JVM needs to compile bytecode to machine language before it runs). We have this setup as a shared folder per-node that is shared into multiple instances of our application. This also helps with updating the application as most unmodified code will already be cached on disk. Lastly, you can generate this during your image builds and ship it alongside the application, you can also have read-only and read-write layers for quite a lot of customization and optimization options.
- You can have a JIT server that the JVM will connect to in order to pass JIT and AOT requests to. This JIT Server can be shared by many instances of your application, and can cache code so that if different JVMs request compilation of the same bytecode that the cached version will be used. This integrates with the Shared Classes Cache, and the server can be networked so that you can have it running on a fast machine with a lot of available CPU resources.

The OpenJ9 project also separates development of the runtime from the integration of it into a given JDK version. This means that if you're running JDK 8 or JDK 11 based applications that you will still receive almost all of the JVM benefits without having to upgrade to a newer JDK release. This can be a big deal for those older JDKs, though this isn't a factor for us as we upgrade to major LTS releases soon after they release (we're about to go to JDK 21 actually).

So I'd say that if you run containerized Java applications in Kubernetes or in similar environments that you might gain a lot by looking into OpenJ9. The only real downside is that they sometimes lag a bit behind on releasing builds for quarterly JDK releases, but this hasn't really been a big deal for us.

[bug77]

You do know that IBM helped create the Apache and Eclipse software foundation and is a major contributor to both and contributed so funding to the tune of billions in the late 90's and core code to Linux that they were accused of ripping of Unix and had to fight a major lawsuit from "SCO" for years? It's a large company, sometimes they throw code over the wall and sometimes they are key contributors. It depends on the project.

Don't mind me, I was just speaking from experience...

[spicfoo]

Don't mind me, I was just speaking from experience...

Yeah, so am I. I am also giving you the history.

[bug77]

We're using it, and have been since whenever JDK 13/14 were current. At the time it had much better resource handling around running in a container, it had more aggressive behavior around de-committing memory back to the OS (it has heuristics around detecting when an application is idle in order to pro-actively run GC cycles). We saw a substantial decrease in memory consumption per-pod when we switched to it, which allowed us to increase density on our Kubernetes nodes by a fair bit.

Additionally the runtime takes a more opinionated approach to auto-configuration of the JVM. There's an expection around running Hotspot that if you want to optimize it that you'll need to get your hands dirty with modifying the various configuration knobs. This is less true with OpenJ9, it's more so that you choose a specific "profile" (though it does a good job choosing one automatically depending on available resources) and then it will try to dynamically adjust certain values as behavior changes. This has led to less Ops time spent trying to optimize the JVM while still retaining good performance.

There are some other benefits as well:
- The Shared Classes Cache feature is really nice. Basically the JVM can be configured to persist compiled JIT and AOT code to disk. This cache can be read by multiple running JVMs at the same time (so code compilation only needs to happen once) which can dramatically reduce startup time and resource use (since the JVM needs to compile bytecode to machine language before it runs). We have this setup as a shared folder per-node that is shared into multiple instances of our application. This also helps with updating the application as most unmodified code will already be cached on disk. Lastly, you can generate this during your image builds and ship it alongside the application, you can also have read-only and read-write layers for quite a lot of customization and optimization options.
- You can have a JIT server that the JVM will connect to in order to pass JIT and AOT requests to. This JIT Server can be shared by many instances of your application, and can cache code so that if different JVMs request compilation of the same bytecode that the cached version will be used. This integrates with the Shared Classes Cache, and the server can be networked so that you can have it running on a fast machine with a lot of available CPU resources.

The OpenJ9 project also separates development of the runtime from the integration of it into a given JDK version. This means that if you're running JDK 8 or JDK 11 based applications that you will still receive almost all of the JVM benefits without having to upgrade to a newer JDK release. This can be a big deal for those older JDKs, though this isn't a factor for us as we upgrade to major LTS releases soon after they release (we're about to go to JDK 21 actually).

So I'd say that if you run containerized Java applications in Kubernetes or in similar environments that you might gain a lot by looking into OpenJ9. The only real downside is that they sometimes lag a bit behind on releasing builds for quarterly JDK releases, but this hasn't really been a big deal for us.

About the "other benefits":
#1 is called Class Data Sharing (https://docs.oracle.com/javase/8/doc...a-sharing.html) and is not particular to OpenJ9. It's just not in widespread use so not many people know about it. Again, mostly superseded by native-image and AOT compilation.
#2 is also not particular to OpenJ9 (https://ieeexplore.ieee.org/document/5679914), though I can't recall where else I have this implemented.