5 ms·

And then we can have Clojure on bare metal, and we're almost back to LISP machines!

by jpt4 6y ago

skissane 6y ago
This doesn't directly execute JVM bytecode in hardware. 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.
- jojobas 6y ago
  The lines are somewhat blurred even in historical LISP machines. Microcode is hardware.
  - fiddlerwoaroof 6y ago
    Yeah, as long as you can “polyfill” or “monkeypatch” in the new JVM instructions, it’s not a huge problem: ideally you take a page from IBM’s TIMI, and you treat compilation as a form of caching: you store the JVM code on permanent storage, and compile it to the underlying hardware on first execution, saving the result until the CPU is upgraded.
  - kazinator 6y ago
    Microcode obviously isn't hardware since it is program we can replace. It is firmware.
- jecel 6y ago
  Note that its "custom stack machine instruction set" is an interesting subset of Java bytecodes. The most common bytecodes are interpreted by a single narrow microcode instruction while the more complex ones are executed by little programs. A wider and more parallel microcode would make the complex instructions faster but would make the hardware larger without helping the simple bytecodes very much. 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.
- jonjacky 6y ago
  Some of the bytecodes are executed directly, others are translated to microcode sequences, others are implemented in software. From the linked paper: "... 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."
- rjsw 6y ago
  > This doesn't directly execute JVM bytecode in hardware. Lisp Machines didn't directly execute their documented instruction set. JOP works in exactly the same way as commercial Lisp Machines.
- embrassingstuff 6y ago
  Is the JVM spec itself really a moving target ? 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.
  - skissane 6y ago
    > Is the JVM spec itself really a moving target ? 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.) [1] https://docs.oracle.com/javase/specs/index.html https://docs.oracle.com/javase/specs/index.html

And then we can have Clojure on bare metal, and we're almost back to LISP machines!

by jpt4 6y ago

And then we can have Clojure on bare metal, and we're almost back to LISP machines!

This doesn't directly execute JVM bytecode in hardware. 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.

jojobas 6y ago
The lines are somewhat blurred even in historical LISP machines. Microcode is hardware.
- fiddlerwoaroof 6y ago
  Yeah, as long as you can “polyfill” or “monkeypatch” in the new JVM instructions, it’s not a huge problem: ideally you take a page from IBM’s TIMI, and you treat compilation as a form of caching: you store the JVM code on permanent storage, and compile it to the underlying hardware on first execution, saving the result until the CPU is upgraded.
- kazinator 6y ago
  Microcode obviously isn't hardware since it is program we can replace. It is firmware.
jecel 6y ago
Note that its "custom stack machine instruction set" is an interesting subset of Java bytecodes. The most common bytecodes are interpreted by a single narrow microcode instruction while the more complex ones are executed by little programs. A wider and more parallel microcode would make the complex instructions faster but would make the hardware larger without helping the simple bytecodes very much. 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.
jonjacky 6y ago
Some of the bytecodes are executed directly, others are translated to microcode sequences, others are implemented in software. From the linked paper: "... 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."
rjsw 6y ago
> This doesn't directly execute JVM bytecode in hardware. Lisp Machines didn't directly execute their documented instruction set. JOP works in exactly the same way as commercial Lisp Machines.
embrassingstuff 6y ago
Is the JVM spec itself really a moving target ? 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.
- skissane 6y ago
  > Is the JVM spec itself really a moving target ? 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.) [1] https://docs.oracle.com/javase/specs/index.html https://docs.oracle.com/javase/specs/index.html