Memory Management ToolKit (MMTk) is a portable and high performance memory manager that includes various garbage collection algorithms and provides clean and efficient interfaces to cooperate with language implementations. MMTk features highly modular and highly reusable designs. It includes components such as allocators, spaces and work packets that GC implementers can choose from to compose their own GC plan easily.
Logically, this crate includes these major parts:
- GC components:
- Allocators: handlers of allocation requests which allocate objects to the bound space.
- Policies: definitions of semantics and behaviors for memory regions. Each space is an instance of a policy, and takes up a unique proportion of the heap.
- Work packets: units of GC work scheduled by the MMTk’s scheduler.
- GC plans: GC algorithms composed from components.
- Heap implementations: the underlying implementations of memory resources that support spaces.
- Scheduler: the MMTk scheduler to allow flexible and parallel execution of GC work.
- Interfaces: bi-directional interfaces between MMTk and language implementations i.e. the memory manager API that allows a language’s memory manager to use MMTk and the VMBinding trait that allows MMTk to call the language implementation.
VM-to-MMTk interface: safe Rust APIs.
GC algorithms from the MMTk suite.
Memory policies that can be used for spaces.
A general scheduler implementation. MMTk uses it to schedule GC-related work.
Utilities used by other modules, including allocators, heap implementation, etc.
MMTk-to-VM interface: the VMBinding trait.
An MMTk instance. MMTk allows multiple instances to run independently, and each instance gives users a separate heap. Note that multi-instances is not fully supported yet
A mutator is a per-thread data structure that manages allocations and barriers. It is usually highly coupled with the language VM. It is recommended for MMTk users 1) to have a mutator struct of the same layout in the thread local storage that can be accessed efficiently, and 2) to implement fastpath allocation and barriers for the mutator in the VM side.
Allocation semantics that MMTk provides. Each allocation request requires a desired semantic for the object to allocate.
BarrierSelector describes which barrier to use.
Each GC plan should provide their implementation of a MutatorContext. Note that this trait is no longer needed as we removed per-plan mutator implementation and we will remove this trait as well in the future.
This trait represents an object queue to enqueue objects during tracing.
A plan describes the global core functionality for all memory management schemes. All global MMTk plans should implement this trait.
A GC worker’s copy allocator for copying GCs. Each copying policy should provide their implementation of PolicyCopyContext. If we copy objects from one policy to a different policy, the copy context of the destination policy should be used. For example, for generational immix, the nursery is CopySpace, and the mature space is ImmixSpace. When we copy from nursery to mature, ImmixCopyContext should be used. Note that this trait should only be implemented with policy specific behaviors. Please refer to GCWorkerCopyContext which implements common behaviors for copying.