Skip to: Site menu | Main content

Metacircular Research Platform

Home Add comment to Wiki View in Wiki Edit Wiki page Printable Version

Welcome to the Metacircular Research Platform (MRP), a new design effort in building performant multipurpose metacircular systems. Metacircularity is a property whereby a system and its run-time are all written in the same programming language. MRP is written in Java, including libraries, compilers and garbage collectors. It uses this metacircular platform to develop runtimes for binary translators and is a basis for operating system research.

Features of MRP include:

  • written in Java - memory safety is a given
  • highly object-oriented design
  • develop programming language runtimes in a modern garbage collected environment (with precise performant garbage collection for free)
  • builds on the popular RVM code base [#1]
  • performance around state-of-the-art, but non-metacircular, runtimes
  • cross platform development, Windows, Linux and OS/X all supported
  • 32 and 64bit Intel support

The purpose of MRP is to provide an alternative to conventional runtimes (such as LLVM and HotSpot) that aren't metacircular and consequently don't practice what they preach in terms of cross-platform portability, or the ease at which they can be adapted as a runtime for other systems.

Explore MRP via the user guide.


Easier to edit code base!

The latest source tree of MRP now includes a substantial refactoring. This refactoring eliminates ArchitectureSpecific! ArchitectureSpecific was a device devised in Jikes RVM 2.9 where at build time classes were generated that selected what architecture the code base was to be compiled for. This mechanisms confuses IDEs and means that only one code base may be edited at a time. This leads to changes in one architecture or word size breaking another. With MRP this headache is gone! This also means that you can explore areas that are better supported on one architecture than another, such as instruction scheduling. Another feature is that the optimizing compiler makes better use of packages, and common operators and instruction formats are shared. Its now intuitive where architectural dependence is being brought into the system.

MRP is now running with Apache Harmony 5.0M10 (milestone 10) or GNU Classpath 0.98. Other than keeping MRP up-to-date with bug fixes and performance improvements (although sometimes the bug fixes degrades the latter) this allows MRP to run applications such as ECJ or x10c either with Apache Harmony or GNU Classpath. Of course SPECjvm2008 still only works with Harmony.

Recent work on the baseline compiler for faster bytecode implementations and bytecode merging show speed ups from a few percent to 5%. This performance matters as the baseline compiler is the baseline that the adaptive optimization system attempts to improve upon. For example, a 5% faster baseline compiler means that code needs to be hotter (say 5%) before the adaptive optimization system thinks its worth involving the heavy duty optimizing compiler. Early JVMs didn't provide adaptive optimization systems and so relied upon this performance. For more realistic benchmarking this performance is also important, as users notice start up costs whereas they may never appreciate the benefit of GC and compilers optimization algorithms.

Comparing performance with Jikes RVM shows MRP is now consistently faster, combined with the enabled execution of programs like SPECjvm2008 and ecj, numerous bug fixes, and of course execution on Windows, MRP is the metacircular development platform of choice.

1. A list of differences between MRP and Jikes RVM is maintained here.