And then we can have Clojure on bare metal, and we're almost back to LISP machines!
It provides a stack machine architecture, and translation from JVM bytecode to its custom stack machine instruction set. I think the theory is that translating from one stack machine to another is a better way than existing JVM implementations which translate the JVM stack machine to register machine instructions (x86/ARM/etc). It may be more elegant in theory, but I doubt the benefits in practice are enough to justify the switching costs.
The biggest problem with any Java-in-hardware design, is the JVM is a moving target (and it is moving faster now than it used too), and without a sustained engineering investment you soon get left behind. Plus, with custom silicon (ASIC), new features will require new hardware. At least this is an FPGA design, so you can field-upgrade the FPGA – but the price-performance of an FPGA is poor, especially as this is a platform for general-purpose computation rather than building some kind of specialised computational accelerator. Although, since it is not directly executing JVM bytecode in hardware, it may be possible to support some newer JVM features just by updating the translation software.
But a cool research project nonetheless.
"... direct implementation of all bytecodes in hardware is not a useful approach ... Microcode is the native instruction set for JOP. Bytecodes are translated, during their execution, into JOP microcode. This translation merely adds one pipeline stage to the core processor and results in no execution overheads ... 43 of the 201 different bytecodes are implemented by a single microcode instruction, 93 by a microcode sequence, and 40 bytecodes are implemented in Java."
The focus of this project is real time instead of absolute performance, so things like caches are added in only limited ways since they get in the way of predictable execution times.
Lisp Machines didn't directly execute their documented instruction set.
JOP works in exactly the same way as commercial Lisp Machines.
I am working on a heavily customized java7/jvm7 internals engine. So I am years behind.
But arent most of the changes in the language / internal implementation ?
I agree however that trying to chase commodity processors is a fools errand.
Yes, it is. Every new Java release brings a new JVM spec and a new version of the classfile format [1]. How much changes varies from release to release – in some Java releases, little changes other than the classfile version number; in other Java releases, there are significant new features – new opcodes, new class file attributes, new constant pool entry types, etc.
> I am working on a heavily customized java7/jvm7 internals engine. So I am years behind.
The most obvious thing you'd be missing would be support for the CONSTANT_Dynamic_info, CONSTANT_Module_info, and CONSTANT_Package_info constant pool entries.
There are a bunch of new classfile attributes, but you may be able to get away with just ignoring the newer ones, at the cost that certain newer features won't work correctly (such as modules introduced in Java 9).
I don't think they've added any new opcodes since the introduction of invokedynamic in Java 7. (But, there is always the chance that some future Java release will.)