jmurmel VS OpenJ9

See also format.lisp for what I have so far. This will also run with sbcl and/ or abcl. If you've made it this far I'd also appreciate feedback on whether my chosen subset (see the comment at the top of the file) of Common-Lisp's format is somewhat useful and/ or which features you would miss the most.

JMurmel also has commandline flags to turn off language features for experimentation purposes, see e.g. implementing cons, car and cdr in Lambda Calculus.

To my defense, I have started my Lisp compiler/ interpreter mostly for recreational purposes to do the exact opposite of what the checkstyle nazis at my $job demand.

Murmel:

I may be a little late to the party but here's my Murmel solution:

Code is on Github, the latest release with a precompiled jar is at Release V 1.3.

Re: automated tests; there are JUnit tests in https://github.com/mayerrobert/jmurmel/tree/master/lambda/src/test/java, and the files in https://github.com/mayerrobert/jmurmel/tree/master/lambda/src/test/lisp are run automatically, too, and their output and result is checked. Maybe I should add a file HACKING.md or something that gives an intro of the project structure and build system?

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!