Allow setting object metadata for VM space objects. Expose VO bit under a feature. #1248
Conversation
qinsoon
force-pushed
the
vo-bit-access
branch
from
15c5472 to
316321a
Compare
qinsoon
force-pushed
the
vo-bit-access
branch
from
316321a to
21d008c
Compare
src/util/metadata/vo_bit/mod.rs
Outdated
| /// Objects in the VM space are allocated/managed by the binding. This functio provides a way for | ||
| /// the binding to set VO bit for an object in the space. | ||
| #[cfg(feature = "vm_space")] | ||
| pub fn set_vo_bit_for_vm_space_object<VM: VMBinding>( |
There was a problem hiding this comment.
Currently the mmtk::util::metadata::vo_bit module is pub(crate), and set_vo_bit_for_vm_space_object is not re-exported. So this method is still inaccessible to the VM binding although it is pub.
I suggest we make the vo_bit module pub, but make every pub items inside the vo_bit module pub(crate), and make set_vo_bit_for_vm_space_object pub. Then the VM binding can call this function by mmtk::util::metadata::vo_bit::set_vo_bit_for_vm_space_object.
I intended to do this refactoring anyway, and remove the is_mmtk_object feature, and move everything related to is_mmtk_object into vo_bit itself (see this issue).
There was a problem hiding this comment.
I made the vo_bit module public. All the existing functions with pub are changed to pub(crate). VO_BIT_SIDE_METADATA_SPEC is exported from this module if the feature vo_bit_access is enabled.
There was a problem hiding this comment.
But I removed this function set_vo_bit_for_vm_space_object. I realized that a binding needs to set all the object metadata to properly initialize an object in the VM space. I added a function MMTK::initialize_vm_space_object() which calls SFT::initialize_object_metadata on vm_space.
src/util/metadata/vo_bit/mod.rs
Outdated
| "{} is not in VM space", | ||
| object | ||
| ); | ||
| set_vo_bit(object); |
There was a problem hiding this comment.
This sets a single VO bit at a time. Depending on the density of objects in the VM space, if this is a bottleneck, we can provide another function that allows the VM binding to provide a bitmap directly, and memcpy into our VO bit metadata (in a single pass, or chunk by chunk).
There was a problem hiding this comment.
I agree, but I feel this is out of scope for this PR.
Instead add initialize_vm_space_object.
qinsoon
force-pushed
the
vo-bit-access
branch
from
ed1942d to
ed4ea46
Compare
qinsoon
changed the title
|
binding-refs |
This PR updates to mmtk-core: mmtk/mmtk-core#1248. This allows us to remove the duplicate code for vo bit. --------- Co-authored-by: mmtkgc-bot <[email protected]>
This PR changes a few things for vo bit:
MMTK::initialize_vm_space_object.vo_bit_accessto expose VO bit and a binding may use it at its own risk.The second is needed for Julia. The Julia binding uses MMTk immortal allocation or VM space for a region of memory, and pop the regions with boot image objects with no clear way to identify each object. The easist workaround is to bulk set VO bit for the region. The problem from this is that MMTk cannot identify valid objects in those regions. However, Julia binding only uses VO bit for pinning objects. Objects in the immortal space or the VM space will not be moved so failing to pinning objects in those regions is benign. Currently the Julia binding duplicates a bunch of side metadata code to bulk set VO bit only using the VO bit side metadata base address. See mmtk/mmtk-julia#200