I know the link stresses that correctness and code clarity are the primary goals of this project, but I’m curious if performance is a goal as well? Do you hope that people will run “real” workloads with this or use it to embed other software in their Go applications?
Author here: Right now we're entirely focused on getting parity of functionality so that anything that runs on the Hotspot JVM runs similarly on Jacobin. There's still a lot of work to do to get there. However, once we do get there, we'll start working on performance.
Thanks for asking. I've always thought of the JVM as magical technlogy--I'm certainly not alone in that view. But in trying to learn more about it, I was greatly frustrated by the difficulty of reading the code base.
As you likely know, the Hotspot JVM is open source. But reading the code is very difficult, in part because it grew organically and in part because of its unusual design, in which many actions are buried deep at the end of a long series of function calls involving unexpected classes and unusual methods, etc.
This led me to thinking there would be value in a JVM written as a single cohesive codebase. And given that there is a 300+ page JVM specification and a reference implementation, I thought to myself, how long could this take? Two years later, and with help from two major contributors, we're still finding out! ;-)
Eventually, we hope, it will be a fun/interesting experience for users to pop open their Go IDE and watch a Java program execute--which is why we're intent on making sure it's written in 100% go.
In a larger context, Jacobin might eventually be useful as an embeddable JVM.
Since they emphasize cohesiveness and clear code, the goal seems to be more on the educational side. It doesn’t look like they’d want to implement JIT bytecode compilation.
