Java supports exotic reference types like weak references. These require close integration with the GC, and Go doesn't support them, so Go's GC can't be used to implement them.
Not to take away from the author's effort, a basic JVM is not hard to implement. It's easier than writing a JavaScript or a Ruby interpreter, as the Java bytecode was designed for simple execution.
What is a lot of work is writing a high-performance JVM (with a good optimizing JIT and a good GC), getting the details right (especially the Java memory model), and supporting "advanced" features such as JNI and JVMTI.
I was going to say: "the hard part of a JVM is the JIT, GC and the cooperation between. As it stands now I am not sure it's possible to write a good JVM on anything but C/asm level language."... But I see it's already done.
Chris, although it's slightly off topic I just want to fanboy your work for a second. Your blog posts about how Graal/Truffle can inline C into Ruby and vice-versa and beat Ruby+C, all on the JVM, is the most mind blowing compiler tech I've ever seen.
Saying Graal performs about as well as C2 and sometimes better is modest. The Graal/Truffle combo does a lot more than C2 can ever do. It is only really comparable if you ignore the astonishing capabilities it has vs the competition.
For readers who are not aware of this work, and who have an interest in VM/compiler technology, I strong recommend checking out Chris' blog and the Graal/Truffle presentations that are floating around. Basically they've built a program that converts simple syntax tree interpreters into full blown JIT compilers. It means that basically any toy scripting language can have similar performance to, say, Javascript on V8, just by writing the base interpreter with their framework.
But where it gets really crazy is when you write an interpreter for C or (say) Objective-C, and start to get aggressive speculative just in time compilation with seamless cross language optimisation, to the extent that C code can actually be run on a compacting garbage collector.
Hah, I'm actually quite grateful that you didn't actually link to his blog (presumably[1]?) -- not because it's not interesting, but because if I hadn't tried to find "chris' blog" on truffle/graal, I wouldn't have come across:
I've yet to read through [1], but the series above (so far up top 4 parts) gives a nice overview of truffle/graal -- and some ideas as to how it is different/similar to rpython/pypy. Be sure to also skim the comments, as they provide some input to why things are/starts out slow, and how to fix it (if it can be fixed).
Didn't realize there'd actually materialized any actual released code from the graal project -- glad it has (quite a while ago, apparently)!
> It means that basically any toy scripting language can have similar performance to, say, Javascript on V8, just by writing the base interpreter with their framework.
That actually sounds a lot like what RPython from PyPy enables.
Not aware of any direct comparisons. Perhaps I am engaging in hyperbole :) The reason I said that is I thought RPython is mostly for speeding up Python, and wasn't aware of HippyVM. There are tutorials on how to use Truffle for other languages and some apparently useful implementations though.
RPython is definitely a Python-first thing. PyPy is the only VM written in it that's actually production-ready at the moment. I'm guessing that has more to do with effort invested than any real limitations on RPython's part though. I'll definitely read up more on Truffle. :)
I don't know if it could or couldn't be done well in RPython, but one application of Truffle that shows off how well it generalises to other languages is a C interpreter. We use it to interpret Ruby C extensions.
- How is the performance?
- Is a GC implemented separately or is the Go one directly used (awesome!)?
- How do calls to native JNI things operate (through CGO)? Does it work?