openj9

I keep forgetting about J9 but they're not doing themselves any branding favors since there actually is J17 on J9 :-/ https://github.com/eclipse-openj9/openj9/blob/openj9-0.35.0/... (Also that 0.35 versioning ...) As best I can tell, these are the docker images: https://hub.docker.com/_/ibm-semeru-runtimes $ docker run --rm ibm-semeru-runtimes:open-11-jdk java -version openjdk version "11.0.17" 2022-10-18 IBM Semeru Runtime Open Edition 11.0.17.0 (build 11.0.17+8) Eclipse OpenJ9 VM 11.0.17.0 (build openj9-0.35.0, JRE 11 Linux amd64-64-Bit Compressed References 20221031_559 (JIT enabled, AOT enabled) OpenJ9 - e04a7f6c1 OMR - 85a21674f JCL - a94c231303 based on jdk-11.0.17+8)

Java Licensing: If you want to pay for a supported Java, with long term ongoing patches: call a commercial vendor of Java such as Oracle, Azul Systems, etc. If you want a free and open source Java runtime, use Open JDK. Some sources of OpenJDK pledge to backport bug fixes from newer versions for some number of years. Or you can simply make sure your product continues to run on newer versions -- which for Java, according to history, has been easy to do. Where to get Open JDK: Adopt Open JDK https://adoptopenjdk.net/ https://github.com/AdoptOpenJDK https://github.com/ojdkbuild/ojdkbuild Open JDK http://openjdk.java.net/ Azul Systems Zulu http://www.azul.com/downloads/zulu/ Amazon https://aws.amazon.com/fr/corretto/ https://github.com/corretto Eclipse https://www.eclipse.org/openj9/ https://adoptopenjdk.net/releases.html?variant=openjdk11

The IBM J9 JVM was open sourced and now lives as the Eclipse OpenJ9 project [1]. We rely on interpreter profiling (block frequency, and value profiling) before the JIT gets it's hands on the method. Once the JIT has determined the cost/benefit is right for a JIT compile we will run through an extended basic block ordering optimization which will lay out the code by block frequency calculated from the taken vs. not taken profiling information on the branch bytecodes given to us by the interpreter. The persistence portion you mention between runs is our AOT capability in which we are able to cache JIT method compilations on disk and load them between different JVM invocations to greatly speed up startup performance. There is a recent series of blog posts on the AOT technology in OpenJ9 in [2]. [1] https://github.com/eclipse/openj9 [2] https

This method of design is called a Continuation Passing Style Interpreter. [1] Here's a production version from OpenJ9's JVM ByteCode Interpreter. [2] [1] https://kseo.github.io/posts/2017-01-09-continuation-passing... [2] https://github.com/eclipse/openj9/blob/01be53f659a8190959c16...

You're showing the sum of all times, but do the times at least look better after the first run (with -Xshareclasses anyway) ? Depending on how smoothly your experimentation went, you may also have to destroy a pre-existing cache before you really measure it (java -Xshareclasses:destroy) as it could have stale classes in it from an earlier run. Would you be willing to open an issue with more details at http://github.com/eclipse/openj9/issues so we can look into it?

This is really interesting: CUDA support out of the box[1]. I've never seen this before, does any other JVM do it? [1] https://github.com/eclipse/openj9/tree/master/runtime/cuda

You could also check out Eclipse OpenJ9's -Xgcpolicy:metronome option. It only works on Linux X86-64 at the moment, but it is designed to better regulate GC pauses. If you want to learn more, you can open an issue to ask for more details at https://github.com/eclipse/openj9/issues .

I opened an issue where discussion on OS X support can happen: https://github.com/eclipse/openj9/issues/36