Function mmtk::memory_manager::mmtk_init

pub fn mmtk_init<VM: VMBinding>(builder: &MMTKBuilder) -> Box<MMTK<VM>>

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:

1. Create an crate::MMTKBuilder instance.
2. Set command line options for MMTKBuilder by crate::memory_manager::process or crate::memory_manager::process_bulk.
3. 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 implement VMCollection::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.