MMTk is under active development and is not yet ready for production use. However, even at this early stage, GC researchers and VM developers can start exploring it and using it experimentally.
If you are a GC researcher, you can start working with the code base now, although the internal abstractions are subject to change and the mechanisms provided by MMTk may not yet be optimal. (Read the tutorial for more information.)
If you are a language implementer, there should already be enough in place for you to start porting to MMTk. (Read the porting guide for more information.)
Features
Implemented collectors
We have implemented several collectors (called “plan” in MMTk’s terminology). The code for the plans is in the mmtk-core.
- NoGC: It never does any GC. Will panic when the heap memory is exhausted. Similar to the Epsilon GC in OpenJDK. Useful for initial porting.
- MarkSweep: The classic non-moving mark-sweep algorithm. It has a segregated free-list allocator we implemented in Rust using MiMalloc as a reference.
- MarkCompact: The classic compacting mark-compact algorithm.
- SemiSpace: The classic evacuating semi-space algorithm.
- GenCopy: A generational copying collector. It has an evacuating nursery, and uses the semi-space algorithm for the mature space.
- Immix: A space-efficient high-throughput mark-region collector, with opportunistic
defragmentation. See this paper. It has several variants:
- GenImmix: A generational collector with an evacuating nursery, using Immix for the mature space.
- StickyImmix: A variant of Immix that implements in-place generational GC without an additional evacuating nursery. It uses the mark bit (i.e. the “sticky mark bit”) to identify old objects during nursery GC.
- LXR: A concurrent collector based on Immix, having both low latency and high throughput. It uses a combination of reference counting and tracing algorithms. See this paper. (Note that the LXR plan and the OpenJDK binding that supports LXR have not merged into master branches, yet. Here are the links to the branches of mmtk-core and mmtk-openjdk.)
The original Java MMTk from which the Rust MMTk has evolved supports a large number of collectors, and we will be incorporating many of those in the near future.
Officially supported bindings
We have several officially supported VM bindings, which are:
- OpenJDK: https://github.com/mmtk/mmtk-openjdk
- JikesRVM (Using the Rust MMTk for GC instead of JikesRVM’s original MMTk): https://github.com/mmtk/mmtk-jikesrvm
- V8: https://github.com/mmtk/mmtk-v8
- Ruby: https://github.com/mmtk/mmtk-ruby
- Julia: https://github.com/mmtk/mmtk-julia
There are other VM bindings developed by third parties, such as GHC, PyPy, Scala/Native, etc.
Feature matrix
Each VM binding supports a subset of collectors (called “plan” in MMTk’s terminology) the MMTk core provides, depending on development progress and VM requirements.
| Plan | OpenJDK | JikesRVM | V8 | Ruby | Julia |
|---|---|---|---|---|---|
| NoGC | Yes | Yes | Yes | Yes | Yes |
| MarkSweep | Yes | Yes | No | Yes | Yes |
| MarkCompact | Yes | No | No | No (pin) | No (pin) |
| SemiSpace | Yes | Yes | No | No (pin) | No (pin) |
| GenCopy | Yes | No | No | No (pin) | No (pin) |
| Immix | Yes | No | No | Yes | Yes |
| GenImmix | Yes | No | No | No (pin) | No (pin) |
| StickyImmix | Yes | No | No | WIP | Yes |
| LXR | Yes | No | No | No | No |
Notes:
- “No (pin)” means the VM binding can not use the specified plan because the VM requires object pinning while the plan does not support object pinning.
- “WIP” means the support for the specified plan is currently under development.
Performance
We track performance for a number of collectors. For example: