andrewbinstock

Joined 14 years ago

Karma
2,623
Submissions
213
Member since
Jul 10
Lead developer on Jacobin (JVM written in go--jacobin.org) Headed up Java Magazine (at Oracle). Earlier, editor in chief of Dr. Dobb's Journal, the original programming 'zine, and several earlier publications.

@platypusguy.

All comments intended to be helpful. If they're not, let me know.

View on Hacker News

Recent submissions

Comment · 1 year ago
A JVM written in go. [0] We're committed to a high-quality implementation that works reliably--so our test code is > 2.x the size of our production code. We can already run lots of classes, but the finished product won't be ready for alpha testing until, we hope!, end of this year.

[0] jacobin.org

Comment · 3 years ago
Lead dev here. I gave a detailed reply earlier. Grep for "I've always thought of the JVM as magical technlogy" on this page and you'll find it.
Comment · 3 years ago
Lead dev here. It's been an amazing amount of work. I'd change the above adage to: Every 10% is 90% of the work!
Comment · 3 years ago
Lead dev here. Some very cool ideas in there. Will copy/paste this into our task tracker on YouTrack for further consideration. Much appreciated.
Comment · 3 years ago
Comment · 3 years ago
Author here. Zero-length arrays are used in the narrow domain you mention. but they are rare in bread-and-butter Java programming. Given some of the other comments on this page, you can see that this aspect is new to multiple readers. And in my experience speaking to Java devs, the reaction of surprise is far more common than "of course, I use them."
Comment · 3 years ago
Author here. Thanks for your comment. It's sometimes a little difficult to know how deeply to go into the innards of the JVM before readers' eyes glaze over and they can't follow. I'll bear in mind for future articles in this series that I can/should go deeper than the present level.
Comment · 3 years ago
Author here. This is simply a comment on the way that Java refers to the subarrays. I believe most developers would think of the first subarray as being referenced with [0], rather than with no index at all. That's all the comment was intended to point out.
Comment · 3 years ago
Comment · 3 years ago
Lead dev here. Yup, that's right. There are a few classes that we will be forced to implement in Go. We're fixated on keeping this number as low as possible, but Thread is one that is inescapable. Class is another inescapable one--if we're to support reflection, etc.
Comment · 3 years ago
Thank you for such kind words!
Comment · 3 years ago
That's a good question. I don't know enough about the new green threads to give you a definitive answer, but it's certainly something we'll examine closely.
Comment · 3 years ago
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.

Comment · 3 years ago
Lead dev here. We've run a couple of benchmarks internally just for kicks. To create a fair comparison, you have to run the Hotspot JVM with the -Xint flag, which says interpret only. Right now our performance is anywhere from 15-25% of the speed of Hotspot with -Xint on small benchmarks. We figure that the use of go alone creates some important portion of that overhead when compared with the C++ of the Hotspot JVM. We're guessing that a well-optimized Jacobin interpreter will eventually get to 50-60% of the Hotspot's -Xint speed.

But we first want to get feature parity, before pivoting to performance. When we have feature parity, we'll run the Computer Language Benchmarks and post the results. That'll be fun to see!

Comment · 3 years ago
Author here: Long ago, when I got the domain, the project was going to be JAva COmpiler to BINary = Jacobin. And as the Jacobins were revolutionaries, it sort of fit the intended project. I don't recall whether Jacobin Magazine was in publication then or not TBH.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton