Design and Project Management: JPC (Java-based x86 emulation)

The first think you may notice upon visiting JPC's web page is the banner loudly proclaiming "JPC is the fast pure Java™ x86 PC emulator".  The second thing you might notice is its absurd URL: www-jpc.physics.ox.ac.uk.  This project is hosted on Oxford's Physics Department's server.  Or maybe it's the fact that all the images on the main page are stretched to fit the designated rectangles, implying a stunning degree of apathy regarding presentation.

This is a project that makes a profoundly impressive claim, but exists somewhere in the abyss of near-forgotten software.  Reading the project's architecture, I was both deeply impressed with some of their technical accomplishments and know-how, and perplexed as to the niche the program was supposed to be filling.  You can get a good impression of project's nature by observing the status and users pages: it is currently an idle project, incapable of booting most x86-based operating systems, used primarily to play DOS games in a browser.

Clearly, this is a project that has a lot to teach.  Much from its successes, and much from its failures.  First, my complaints:

1. Java's portability is meaningless when you're emulating hardware.  This is a very oddly placed abstraction layer.  For you to run an x86 application, you now need to have booted into an operating system and loaded a JVM.  JPC is effectively relying on the JVM to ensure its portability.  In a sense, it's using Java for what a compiler should be used for.
   
   Any application that can be compiled with gcc can be compiled to run on any hardware gcc supports.  If they had written their code in C++ (or even combined Java down to binary, rather than bytecode), they would get the some functionality, but without the performance penalties inherent to the extra abstraction layer.
   
   The only novel deployment area for Java is applets, and those... well, we won't get into applets.
   
2. Follow your own rules: Newman and Dennis (the code's authors) explicitly warn against premature optimization.  "Make it work, make it right, make it fast", right?
   
   Again, looking at the "status" page reveals the only successful emulation behavior to be in DOS.  Now maybe "work" in this context can mean "work quickly"--the program is near useless without it.  They still seem to contradict "Before building each part of each stage, be clear what aspect is being developed and why" by repeatedly insisting that this is supposed to be a full x86 emulator.
3. Be honest about numbers: The project is regularly described as being "fast".  All sorts of benchmarks are given for a prototype using a simplified instruction set.  But the actual x86 emulation?  No mention in the paper.  After searching around, I found a presentation on JPC from which numbers can be derived; it's mentioned that using Java HotSpot, one can get approximately 20 x86 instructions per actual x86.  This translates to around 5%.  Simply put, that level of efficiency is far too slow to compete with most modern virtualization solutions.
4. If you're going to have open code, invite people: They're GPL'd but don't have a CVS or SVN server set-up.  No instructions as to how to contribute.  It might seem like they don't care because I suspect they don't.

That all I said, I'm still damn well impressed.  They were approaching a profoundly difficult problem, and sought a number of avenues to conquer it (at one point looking into the JVM code to find out how classes are managed in memory).  From their work, I learned quite a bit about Java's memory management and techniques for performance optimization.  There are some outstanding ideas in there: unfortunately most of those ideas are either centered around Java optimization or in advantages of virtualization--I remain unconvinced of the synergy between the two.

Curious as to the fate of this project, I fired up the GRUMPs and went off to the distant future: September 2009.  What I found shocked me: the project hasn't budged.