GRUMPS Design: Metacircular Virtual Machines

On only one occasion have I taken self-reference to its logical extreme:  the GRUMPS Superluminal Computation Optimizer.  In an attempt to dramatically enhance the speed of GRUMPS' computations, I designed a system to send instructions back in time so that the results would be available sooner.  The system was profoundly metacircular; not only was the system self-referential, but individual function calls would often be literally self-referential, creating themselves in John Conner-like fashion.

In developing this system, I noticed a paradoxical advantage: it was in some ways far less stable.  A simple bug would cascade rapidly, bringing down the whole system.  The net result was that I'd detect bad code much sooner than normal.  Furthermore, optimizations would often have a substantial affect on the system, shortening recursive invocations and affecting wide swaths of code.

For the most part, I am a high-level developer.  I am grateful for the abstractions granted to me.  I don't always want sweeping power over my system, and metacircularity grants one an extremely intricate power over the informational structure of a system.

This power is further complicated when it is attempting to recreate another system, rather than exist independently.  The Jikes RVM project is a Java-based Java VM, giving the developer far more power than an standard app developer needs, but exactly as much power as a performance theorist needs.  In evaluating such a project, it can be difficult to separate its meta-circular qualities from it's Java qualities.  What value does it derive from being densely recursive, and what value from being Java in particular?

Metacircular VMs (virtual machines written primarily in the same language they execute) are easier to port--only the the boot image, loader, and some memory behavior need to be translated for each operating system.  Most of the environment's behavior is self-referential, meaning it can execute on any environment support the lowest-level operations it specifies.  For a Java VM, metacircularity doesn't offer much to most application developers, since most programmers' applications will be running on a standard JVM anyway.  However, for support tools (like debuggers) and highly-specific performance-dependent niche applications, the ability to optimize the VM and code in the same context could help developers improve application performance, and identify the true bottlenecks in their system.

As a Java application, JikesRVM has some notable advantages and issues.  It gains all the structural benefits of Java--the ease of organization, the simplified modularity, the portability of code.  However, it also gains some of the problems--in particular, the hindered performance.  There is a reason JikesRVM is primarily a research project: it is much slower than the Sun JVM.

It's an excellent playground for testing out optimizations.  Its structure makes it easy for a researcher to get a comprehensive picture of how their work in interacting with the rest of the system.  Furthermore, it is probably the easiest way for a Java developer to understand the inner-workings of a Java VM.  But realistically, most of this theory achieves its fullest impact when done in a language closer to the processor.  Jikes has a long life ahead of it, but that life won't be on your laptop or cell phone.