MMTk is a framework for the design and implementation of memory managers. This repository hosts the Rust port of MMTk.
We maintain an up to date list of the prerequisite for building MMTk and its bindings in the mmtk-dev-env repository.
MMTk can build with a stable Rust toolchain. We pin to a specific Rust version using the rust-toolchain file, and we specify the minimal supported Rust
version (MSRV) in Cargo.toml.
$ cargo buildMMTk also provides a list of optional features that users can choose from.
A full list of available features can be seen by examining Cargo.toml.
By passing the --features flag to the Rust compiler,
we conditionally compile feature-related code.
For example, you can optionally enable sanity checks by adding sanity to the set of features
you want to use.
You can pass the --release flag to the cargo build command to use the
optimizing compiler of Rust for better performance.
The artefact produced produced by the build process can be found under
target/debug (or target/release for the release build).
ci-build.sh shows the builds tested by the CI.
For the best performance, we recommend using a profile-guided optimized (PGO) build. Rust supports PGO builds by hooking into the LLVM profiling infrastructure. The idea is that we gather profiling data by running a representative benchmark and then later use the profiling data as a feedback on making optimization decisions.
It is recommended to choose the best-performing GC for the profiling step. For
example, GenImmix is used for our OpenJDK binding.
We recommend running the GC under stress (using MMTK_STRESS_FACTOR and
MMTK_PRECISE_STRESS=false) in order to tune the profile sample data for the
GC. Multiple invocations of the benchmark are also recommended to reduce
variance.
See the OpenJDK binding for an example of how to make a PGO build.
MMTk does not run standalone. You would need to integrate MMTk with a language implementation. You can either try out one of the VM bindings we have been working on, or implement your own binding in your VM for MMTk. You can also implement your own GC algorithm in MMTk, and run it with supported VMs. You can find up-to-date full API documentation for mmtk-core here.
We maintain three VM bindings for MMTk. These bindings are accessible in the following repositories:
For more information on these bindings, please visit their repositories.
MMTk provides a bi-directional interface with the language VM.
- MMTk exposes a set of APIs. The language VM can call into MMTk by using those APIs.
- MMTk provides a trait
VMBindingthat each language VM must implement. MMTk useVMBindingto call into the VM.
To integrate MMTk with your language implementation, you need to provide an implementation of VMBinding, and
you can optionally call MMTk's API for your needs.
For more information, you can refer to our porting guide for VM implementors.
MMTk is a suite of various GC algorithms (known as plans in MMTk). MMTk provides reusable components that make it easy to construct your own GC based on those components. For more information, you can refer to our tutorial for GC implementors.
We use both unit tests and VM binding tests to test MMTk in the CI.
MMTk uses Rust's testing framework for unit tests. For example, you can use the following to run unit tests.
$ cargo testA full list of all the unit tests we run in our CI can be found here.
MMTk is also tested with the VM bindings we are maintaining by running standard test/benchmark suites for the VMs. For details, please refer to each VM binding repository.
MMTk uses a pinned Rust version in the repository (recorded in the rust-toolchain file). We run
our tests and benchmarks using the pinned Rust version. We recommend using the pinned Rust version
for development. We update the pinned Rust version between releases of mmtk-core to keep it close to
the latest Rust stable release. The release cycle of mmtk-core is six weeks, roughly the same as
Rust itself.
Our minimum support Rust version (MSRV) policy is "N-1" (note that N is NOT the current stable Rust release). That means we also ensure mmtk-core works
properly with the Rust toolchain that is one minor version before the version specified in
rust-toolchain. For example, if rust-toolchain contains "1.61.2", the MSRV will be guaranteed
to be no later than "1.60.0". We may bump MSRV up to "N-1" when we need to make use of new Rust
features or a dependency crate that needs a newer Rust. In other words, we will not eagerly bump the MSRV, and the MSRV can lag behind "N-1" in practice. However, users shouldn't depend on this lag, and are encouraged to keep close to the
latest Rust toolchain rather than relying on an outdated version of Rust.
Note, however, that we may switch to a more conservative MSRV policy in the future when MMTk reaches a stable state.
Thank you for your interest in contributing to MMTk. We appreciate all the contributors. Generally you can contribute to MMTk by either reporting MMTk bugs you encountered or submitting your patches to MMTk. For details, you can refer to our contribution guidelines.