Avian VS OpenJ9

There's been plenty but they've fallen aside for various reasons.

- GCJ (iirc only pre 1.5-1.6 java support so never with generic versions, not sure if they ever implented JNI but relied on their own so libraries with native bindings had to be manually ported iirc)

- Excelsior JET was a strong option for a long time on desktops up until 2018, main selling point was resistance to decompilation but not sure if they ran afoul of Oracle licensing or couldn't keep up with the accelerated pace of JDK releases in later years.

(The below were options to various degrees for iOS developers)

- Avian VM ( https://readytalk.github.io/avian/ ), opensource and seems to be up but never really saw an uptake or proper debug tooling iirc, seems inactive by now.

- Robo VM was another strong option with strong support for IDE debuggers,etc since it was used by gamedevs and the initial libgdx author was involved in it. Sadly they were sold out to Xamarin shortly before MS bought out Xamarin and then promptly shut down since MS only had interest in Xamarin for their C# iOS/Android toolkits.

- RoboVM forks, luckily RoboVM core was liberally licensed so forks were possible for those working on mobile games with iOS ports even if the tooling wasn't as slick as the official RoboVM project (No idea if any of the open source variants have caught up, it was a bit chaotic initially with many forks).

- Intel had(have?) some AOT compiler for Java that was an option for libgdx developers for a while but RoboVM being more "native" had more eyes and no idea if Intel really had a business case for it's Java things ? (

(Funnily enough, I was actually doing an AOT one during late uni times to write a thesis on game GC's (and hoping to maybe commercialize), then Oracle bought out Sun and I wrote a JS AOT prototype instead. Hearing of Oracle vs Goog it felt sane but Oracle did showcase RoboVM later on so maybe it was silly)

Avian

Source

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

On another note, I'm still not sure if there is a viable way to microbench code running on OpenJ9. It seems that there is still no official support from JMH, at least I'm getting warnings such as "This VM is not supported by JMH. The produced benchmark data can be completely wrong". Apparently it should work, however, my results for runs on OpenJ9 show (by a large margin) much higher variance compared to Hotspot which doesn't exactly inspire confidence.

-Xjit:disableGuardedStaticFinalFieldFoldingFlat out improves performance, working around a bug in -XaggressiveEnables performance optimizations and new platform exploitation that are expected to be the default in future releases of OpenJ9. -Xmns128M -Xmnx1024MSets minimum and maximum size of the nursery for the gencon (default) GC. Having a small nursery allows garbage collection to be really fast, especially with how many short lived objects Minecraft makes. These values shouldn't need to be changed.If you want to know more about the gencon GC and its nursery and tenure zones you can find something here. -XdisableexplicitgcDoesn't allow mods to force a full garbage collection. Removes some lagspikes from misbehaving mods. -Xgc:concurrentScavengeLets gencon GC collect garbage in the background, without stopping the game thread to do it. Gives a very noticeable boost to "smoothness". -Xgc:dnssExpectedTimeRatioMaximum=95 -Xgc:dnssExpectedTimeRatioMinimum=70Lets gencon GC know that it's gotta spend most of its time cleaning up the nursery, instead of the rest of the heap. Most of the garbage is in the nursery instead of the tenure zone so this works incredibly well on modded MC.

I like this part "We continue to employ dozens of developers that work directly and openly in the Eclipse OMR and Eclipse OpenJ9 projects at GitHub. IBM doesn’t produce a separate enterprise version of OpenJ9; we don’t hold back any of the innovation in our runtime."

OpenJ9 (heavily based on OpenJDK, especially later versions): https://github.com/eclipse/openj9/blob/master/jcl/src/java.base/share/classes/java/lang/Throwable.java

In 1.18.16 they "added support for compiling projects with OpenJ9". Turns out the hack to access Hotspot's sun.misc.Unsafe doesn't quite work with OpenJ9 . Oh, really? So surprising. This is exactly the reason why the OpenJDK project pushes their encapsulation agenda so hard!