20 years ago, I was a lurker on the JikesRVM (IBM's research project building a JVM in Java) mailing list. JikesRVM is still around, but not terribly active la

20 years ago, I was a lurker on the JikesRVM (IBM's research project building a JVM in Java) mailing list. JikesRVM is still around, but not terribly active last I checked. Oracle is quite late to the game, and I'm just generally sad that Oracle ended up owning Java instead of IBM (or perhaps Google, but my trust in Google seems to be monotonically decreasing). Last I checked, Oracle's AoT compiler threw away any metadata necessary for HotSpot to be able to trace its way trough the native code, so if your AoT-compiled code was part of a hot loop, HotSpot wouldn't be able to perform any inlining or other runtime optimizations of your code. It seems like fixing this would be a first step to having a high performance JVM written in Java with start-up/warm-up time comparable to a JVM written in C++. While we're at it, Erlang/Elixir/BEAM's NIFs seem the right way to implement native code extensions to your VM. You write implementations in your language that get replaced with native versions if the native library is successfully loaded. Maybe your non-native implementation is just a stub that throws if it's called. With a few lines at the top of your module, you can attempt to load one or more native libraries and handle/ignore any errors. This makes it much easier to gracefully degrade if a particular native library isn't available on the local machine (or even available for the platform). It's a real pain to fall back to a Java implementation if the JNI implementation isn't available for any reason.