MMTk is a liberally-licensed open source project developed on GitHub. Contributions are welcome and encouraged. We dual-license with MIT and Apache 2.0 for maximum flexibility and compatibility with the various licenses of the runtimes which we bind to.

The code is organized into multiple repositories.

MMTk-Core

The heart of the project is mmtk-core. The code is entirely Rust and is built as a Rust crate. This is where GC algorithms are implemented and it is home to all MMTk code that is not VM-specific.

Documentation

Documentation for mmtk-core can be found here: tutorial (for MMTk/GC developers), porting guide (for binding developers), and API documentation.

VM Bindings

MMTk uses a pattern of each language runtime depending on four distinct code bases: one is the upstream language runtime, one is the MMTk core, and the other two are bindings. This design pattern ensures that the MMTk core remains host-language agnostic and the host runtime remains neutral to MMTk, while avoiding hot paths that transition between the VM and MMTk.

MMTk makes no assumptions about the implementation language of the host VM (such as OpenJDK or V8). The binding repo associated with a given port performs the necessary impedance matching. It does this by using two code bases, one conceptually close to the language runtime, the other close to the MMTk core.

You can explore the OpenJDK, V8, and JikesRVM bindings on GitHub. Each contains a README file that explains how to build the respective runtime with MMTk. Within each binding repo you will find two code bases, one named after the respective runtime (eg v8 or openjdk), and the other named mmtk. The first of these (e.g. mmtk-openjdk/openjdk) will contain code that is written in the same language as the target VM (C++, for example), and will encode MMTk-specific functionality that for performance reasons needs to be very close to the host VM. For example, this might include write barrier fast paths, or perhaps code that discovers roots. On the other hand, the mmtk code base within the binding (e.g. mmtk-openjdk/mmtk) is written in Rust and contains VM-specific functionality that for performance reasons needs to be very close to MMTk. For example, this might include object scanning.

Runtime Forks

Our intention is to not depend on changes to the host runtime. In the case of V8, this is already true since we have worked with the developers to have an third_party_heap API upstreamed, which allows MMTk integration with no change to V8.

For runtimes where we have not yet upstreamed changes, we maintain forks. For example, OpenJDK and JikesRVM.