API Migration Guide
This document lists changes to the MMTk-VM API that require changes to be made by the VM bindings. VM binding developers can use this document as a guide to update their code to maintain compatibility with the latest release of MMTk.
View control
Choose how many details you want to read.
0.32.0
Allocation options changed
AllocationOptions now has multiple boolean fields instead of one OnAllocationFail field. Now
polling cannot be disabled. Instead we can now poll and over-commit in one allocation.
API changes:
- module
util::alloc::allocatorOnAllocationFail: Removed.AllocationOptions: It now has two boolean fields:allow_overcommitat_safepointallow_oom_call
Variants of the old enum OnAllocationFail should be migrated to the new API according to the
following table:
| variant | allow_overcommit | at_safepoint | allow_oom_call |
|---|---|---|---|
RequestGC | false | true | true |
ReturnFailure | false | false | false |
OverCommit | true | false | false |
Note that MMTk now always polls before trying to get more pages from the page resource, and it may
trigger GC. The old OnAllocationFail::OverCommit used to prevent polling, but it is no longer
possible.
See also:
Removed the notion of "mmap chunk"
Constants such as MMAP_CHUNK_BYTES were related to the implementation details of the memory
mapper, and should not have been exposed.
API changes:
- module
util::conversionsmmap_chunk_align_down: Removed.mmap_chunk_align_up: Removed.
- module
util::heap::vm_layoutLOG_MMAP_CHUNK_BYTES: Removed.MMAP_CHUNK_BYTES: Removed.
Options no longer differentiates between environment variables and command line arguments.
We replaced both Options::set_from_command_line and Options::set_from_env_var with
Options::set_from_string because all options can now be set via either environment variable or
command line arguments.
API changes:
- module
util::optionsOptions::set_from_command_line: Removed.- Use
Options::set_from_stringinstead.
- Use
Options::set_from_env_var: Removed.- Use
Options::set_from_stringinstead.
- Use
Options::set_bulk_from_command_line: Removed.- Use
Options::set_bulk_from_stringinstead.
- Use
- All
<T>inMMTKOption<T>now must implementFromStr.- This means you can parse a string into
Twhen setting anMMTKOption<T>. For example,options.plan.set(user_input.parse()?);.
- This means you can parse a string into
The feature immix_stress_copying is removed.
The feature immix_stress_copying is removed. Bindings can use MMTk options with the following values
to achieve the same behavior as before: immix_always_defrag=true,immix_defrag_every_block=true,immix_defrag_headroom_percent=50
API changes:
- The feature
immix_stress_copyingis removed. - module
util::optionsOptionsincludesimmix_always_defrag, which defaults tofalse.Optionsincludesimmix_defrag_every_block, which defaults tofalse.Optionsincludesimmix_defrag_headroom_percent, which defaults to2.
See also:
0.30.0
live_bytes_in_last_gc becomes a runtime option, and returns a map for live bytes in each space
count_live_bytes_in_gc is now a runtime option instead of a features (build-time), and we collect
live bytes statistics per space. Correspondingly, memory_manager::live_bytes_in_last_gc now returns a map for
live bytes in each space.
API changes:
- module
util::optionsOptionsincludescount_live_bytes_in_gc, which defaults tofalse. This can be turned on at run-time.- The old
count_live_bytes_in_gcfeature is removed.
- module
memory_managerlive_bytes_in_last_gcnow returns aHashMap<&'static str, LiveBytesStats>. The keys are strings for space names, and the values are statistics for live bytes in the space.
See also:
mmap-related functions require annotation
Memory-mapping functions in mmtk::util::memory now take an additional MmapAnnotation argument.
API changes:
- module
util::memory- The following functions take an additional
MmapAnnotationargument.dzmmapdzmmap_noreplacemmap_noreserve
- The following functions take an additional
0.28.0
handle_user_collection_request returns bool
memory_manager::handle_user_collection_request now returns a boolean value to indicate whether a GC
is triggered by the method or not. Bindings may use the return value to do some post-gc cleanup, or
simply ignore the return value.
API changes:
- module
memory_managerhandle_user_collection_requestnow returnsboolto indicate if a GC is triggered by the method. Bindings may use the value, or simply ignore it.
See also:
- PR: https://github.com/mmtk/mmtk-core/issues/1205
- Examples:
- https://github.com/mmtk/mmtk-julia/pull/177: Ignore return value.
ObjectReference must point inside an object
ObjectReference is now required to be an address within an object. The concept of "in-object
address" and related methods are removed. Some methods which used to depend on the "in-object
address" no longer need the <VM> type argument.
API changes:
- struct
ObjectReference- Its "raw address" must be within an object now.
- The following methods which were used to access the in-object address are removed.
from_addressto_address- When accessing side metadata, the "raw address" should be used, instead.
- The following methods no longer have the
<VM>type argument.get_forwarded_objectis_in_any_spaceis_liveis_movableis_reachable
- module
memory_manageris_mmtk_object: It now requires the address parameter to be non-zero and word-aligned.- Otherwise it will not be a legal
ObjectReferencein the first place. The user should filter out such illegal values.
- Otherwise it will not be a legal
- The following functions no longer have the
<VM>type argument.find_object_from_internal_pointeris_in_mmtk_spaceis_live_objectis_pinnedpin_objectunpin_object
- struct
Region- The following methods no longer have the
<VM>type argument.containing
- The following methods no longer have the
- trait
ObjectModelIN_OBJECT_ADDRESS_OFFSET: removed because it is no longer needed.
See also:
- PR: https://github.com/mmtk/mmtk-core/issues/1170
- Examples:
- https://github.com/mmtk/mmtk-openjdk/pull/286: a simple case
- https://github.com/mmtk/mmtk-jikesrvm/issues/178: a VM that needs much change for this
0.27.0
is_mmtk_object returns Option<ObjectReference>
memory_manager::is_mmtk_object now returns Option<ObjectReference> instead of bool.
Bindings can use the returned object reference instead of computing the object reference at the binding side.
API changes:
- module
memory_manageris_mmtk_objectnow returnsOption<ObjectReference>.
See also:
Introduce ObjectModel::IN_OBJECT_ADDRESS_OFFSET
We used to have ObjectModel::ref_to_address and ObjectModel::address_to_ref, and require
the object reference and the in-object address to have a constant offset. Now, the two methods
are removed, and replaced with a constant ObjectModel::IN_OBJECT_ADDRESS_OFFSET.
API changes:
- trait
ObjectModel- The methods
ref_to_addressandaddress_to_refare removed. - Users are required to specify
IN_OBJECT_ADDRESS_OFFSETinstead, which is the offset from the object reference to the in-object address (the in-object address was the return value for the oldref_to_address()).
- The methods
- type
ObjectReference- Add a constant
ALIGNMENTwhich equals to the word size. All object references should be at least aligned to the word size. This is checked in debug builds when anObjectReferenceis constructed.
- Add a constant
See also:
- PR: https://github.com/mmtk/mmtk-core/pull/1159
- Example: https://github.com/mmtk/mmtk-openjdk/pull/283
0.26.0
Rename "edge" to "slot"
The word "edge" in many identifiers have been changed to "slot" if it actaully means slot.
Notable items include the traits Edge, EdgeVisitor, the module edge_shape, and member types
and functions in the Scanning and VMBinding traits. The VM bindings should not only make
changes in response to the changes in MMTk-core, but also make changes to their own identifiers if
they also use "edge" where it should have been "slot". The find/replace tools in text editors and
the refactoring/renaming tools in IDEs should be helpful.
API changes:
- module
edge_shape->slot - type
RootsWorkFactory<ES: Edge>-><SL: Slot>create_process_edge_roots_work->create_process_roots_work
- type
SimpleEdge->SimpleSlot - type
UnimplementedMemorySliceEdgeIterator->UnimplementedMemorySliceSlotIterator - trait
Edge->Slot - trait
EdgeVisitor->SlotVisitor<ES: Edge>-><SL: Slot>visit_edge->visit_slot
- trait
MemorySliceEdge->SlotTypeEdgeIterator->SlotIteratoriter_edges->iter_slots
- trait
Scanningsupport_edge_enqueuing->support_slot_enqueuingscan_object<EV: EdgeVisitor>-><SV: SlotVisitor>
scan_roots_in_mutator_thread- Type parameter of
factorychanged. See typeRootsWorkFactory.
- Type parameter of
scan_vm_specific_roots- Same as above.
- trait
VMBindingVMEdge->VMSlot
See also:
- PR: https://github.com/mmtk/mmtk-core/pull/1134
- Example: https://github.com/mmtk/mmtk-openjdk/pull/274
0.25.0
ObjectReference is no longer nullable
ObjectReference can no longer represent a NULL reference. Some methods of ObjectReference and
the write barrier functions in memory_manager are changed. VM bindings need to re-implement
methods of the Edge, ObjectModel and ReferenceGlue traits.
API changes:
- type
ObjectReference- It can no longer represent NULL reference.
- It is now backed by
NonZeroUsize, and MMTk usesOption<ObjectReference>universally when anObjectReferencemay or may not exist. It is more idiomatic in Rust.
- It is now backed by
- The constant
ObjectReference::NULLis removed. is_null()is removed.from_raw_address(addr)- The return type is changed to
Option<ObjectReference>. - It returns
Noneifaddris not zero. - If you know
addrcannot be zero, you can use the new methodfrom_raw_address_unchecked(addr), instead.
- The return type is changed to
- It can no longer represent NULL reference.
- module
mmtk::memory_manager- Only affects users of write barriers
object_reference_write_pre(mutator, obj, slot, target)- The
targetparameter is nowOption<ObjectReference>. - Pass
Noneif the slot was holding a NULL reference or any non-reference value.
- The
object_reference_write_post(mutator, obj, slot, target)- Same as above.
object_reference_write(mutator, obj, slot, target)- It is labelled as
#[deprecated]and needs to be redesigned. It cannot handle the case of storing a non-reference value (such as tagged small integer) into the slot. - Before a replacement is available, use
object_reference_write_preandobject_reference_write_post, instead.
- It is labelled as
- trait
Edgeload()- The return type is changed to
Option<ObjectReference>. - It returns
Noneif the slot is holding a NULL reference or other non-reference values. MMTk will skip those slots.
- The return type is changed to
- trait
ObjectModelcopy(from, semantics, copy_context)- Previously VM bindings convert the result of
copy_context.alloc_copy()toObjectReferenceusingObjectReference::from_raw_address(). - Because
CopyContext::alloc_copy()never returns zero, you can useObjectReference::from_raw_address_unchecked()to skip the zero check.
- Previously VM bindings convert the result of
get_reference_when_copied_to(from, to)tois never zero because MMTk only calls this after the destination is determined.- You may skip the zero check, too.
address_to_ref(addr)addris never zero because this method is an inverse operation ofref_to_address(objref)whereobjrefis never NULL.- You may skip the zero check, too.
- trait
ReferenceGlue- Note: If your VM binding is still using
ReferenceGlueand the reference processor and finalization processor in mmtk-core, it is strongly recommended to switch to theScanning::process_weak_refsmethod and implement weak reference and finalization processing on the VM side. get_referent()- The return type is changed to
Option<ObjectReference>. - It now returns
Noneif the referent is cleared.
- The return type is changed to
clear_referent()- It now needs to be explicitly implemented because
ObjectReference::NULLno longer exists. - Note: The
Edgetrait does not have a method for storing NULL to a slot. The VM binding needs to implement its own method to store NULL to a slot.
- It now needs to be explicitly implemented because
- Note: If your VM binding is still using
Not API change, but worth noting:
- Functions that return
Option<ObjectReference>memory_manager::get_finalized_objectObjectReference::get_forwarded_object- The functions listed above did not change, as they still return
Option<ObjectReference>. But some VM bindings used to expose them to native programs by wrapping them intoextern "C"functions that returnObjectReference, and returnObjectReference::NULLforNone. This is no longer possible since we removedObjectReference::NULL. The VM bindings should usemmtk::util::api_util::NullableObjectReferencefor the return type instead.
- The functions listed above did not change, as they still return
See also:
- PR: https://github.com/mmtk/mmtk-core/pull/1064
- PR: https://github.com/mmtk/mmtk-core/pull/1130 (for write barriers)
- Example: https://github.com/mmtk/mmtk-openjdk/pull/265
- Example: https://github.com/mmtk/mmtk-openjdk/pull/273 (for write barriers)
Instance methods of ObjectReference changed
Some methods of ObjectReference now have a type parameter <VM>. ObjectReference::value() is
removed.
API changes:
- type
ObjectReference- The following methods now require a generic argument
<VM: VMBinding>:ObjectReference::is_reachableObjectReference::is_liveObjectReference::is_movableObjectReference::get_forwarded_objectObjectReference::is_in_any_spaceObjectReference::is_sane
ObjectReference::value()is removed.- Use
ObjectReference::to_raw_address()instead.
- Use
- The following methods now require a generic argument
See also:
- PR: https://github.com/mmtk/mmtk-core/pull/1122
- Example: https://github.com/mmtk/mmtk-openjdk/pull/272
The GC controller (a.k.a. coordinator) is removed
The GC controller thread is removed from MMTk core. The VM binding needs to re-implement
Collection::spawn_gc_thread and call GCWorker::run differently.
API changes:
- type
GCWorkerGCWorker::run- It now takes ownership of the
Box<GCWorker>instance instead of borrowing it. - The VM binding can simply call the method
worker.run()on the worker instance fromGCThreadContext::Worker(worker).
- It now takes ownership of the
- module
mmtk::memory_managerstart_worker- It is now a simple wrapper of
GCWorker::runfor legacy code. It takes ownership of theBox<GCWorker>instance, too.
- It is now a simple wrapper of
- trait
CollectionCollection::spawn_gc_thread- It no longer asks the binding to spawn the controller thread.
- The VM binding can simply remove the code path related to creating the controller thread.
- Note the API change when calling
GCWorker::runorstart_worker.
See also: