[andrewbinstock]

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.

[riku_iki]

what is the reason for this project to be started? What is the end goal? Why current JVM is not good enough?..

[andrewbinstock]

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.