This looks neat, but it appears to be an 'academic' exercise. I couldn't find any source code written for the JOP (the only project in the Links section was down) after scanning some of the pdfs. I did, however, notice the 64 journal publications the creator has on the subject.
OTOH, he definitely appears to have put a lot of work into this, and I would like to test it out, if I can figure out how.
It doesn't look too hard, if you have an Altera FPGA. Just follow the "Getting Started" link, and it will show you how to download and build the source.
There have been a few runs at this problem. I've wondered for ages why it didn't pick up steam because surely you could get some great performance benefits from it. Any ideas?
Azul systems (http://www.azulsystems.com/) has a special-purpose Java processor, and they do indeed get some impressive speed benefits from it. For example, having single-instruction write barriers in hardware allows them to have nearly-pauseless garbage collection on gigantic heaps.
Here's an excellent google tech talk by Cliff Click of Azul talking about their hardware. Among the firehose of information in that talk, he mentions that the hardware guys wanted to add directly execute JVM bytecode. He told them not to bother since he could JIT it better and they wouldn't be able to support all the bytecodes anyway. I'd love to know more about why that is.
Many of the ARM processor cores have hardware support for the most common Java bytecode operations; that's the "Jazelle" extension that others have been mentioning. (The less common operations are left to software, to keep silicon overhead low.)
Also, Transmeta used to have a processor with configurable instructions so you could get it to mimic a given machine. Why, why why did they not make a JVM instead of trying to compete with Intel on their home ground?
Maybe your board doesn't have a jazelle-capable part, or you lack licensing for it (jazelle isn't publicly documented, sadly). Maybe you do have a bunch of gates left over on your FPGA.
The Jazelle extension requires paying money to access on how to set it up. Also as others have pointed out using hardware supported java prohibits a lot of dynamic optimizations.
ARM seem to be mostly concentrating on the ThumbEE environment now, which is much better documented.
OTOH, he definitely appears to have put a lot of work into this, and I would like to test it out, if I can figure out how.