Function mmtk::memory_manager::mmtk_init
source · pub fn mmtk_init<VM: VMBinding>(builder: &MMTKBuilder) -> Box<MMTK<VM>>
Expand description
Initialize an MMTk instance. A VM should call this method after creating an crate::MMTK
instance but before using any of the methods provided in MMTk (except process()
and process_bulk()
).
We expect a binding to ininitialize MMTk in the following steps:
- Create an
crate::MMTKBuilder
instance. - Set command line options for MMTKBuilder by
crate::memory_manager::process
orcrate::memory_manager::process_bulk
. - Initialize MMTk by calling this function,
mmtk_init()
, and pass the builder earlier. This call will return an MMTK instance. Usually a binding store the MMTK instance statically as a singleton. We plan to allow multiple instances, but this is not yet fully supported. Currently we assume a binding will only need one MMTk instance. Note that GC is enabled by default and the binding should implementVMCollection::is_collection_enabled()
if it requires that the GC should be disabled at a particular time.
Note that this method will attempt to initialize a logger. If the VM would like to use its own logger, it should initialize the logger before calling this method.
Note that, to allow MMTk to do GC properly, initialize_collection()
needs to be called after this call when
the VM’s thread system is ready to spawn GC workers.
Note that this method returns a boxed pointer of MMTK, which means MMTk has a bound lifetime with the box pointer. However, some of our current APIs assume
that MMTk has a static lifetime, which presents a mismatch with this API. We plan to address the lifetime issue in the future. At this point, we recommend a binding
to ‘expand’ the lifetime for the boxed pointer to static. There could be multiple ways to achieve it: 1. Box::leak()
will turn the box pointer to raw pointer
which has static lifetime, 2. create MMTK as a lazily initialized static variable
(see what we do for our dummy binding)
Arguments:
builder
: The reference to a MMTk builder.