Let the VM customize object forwarding implementation #975
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
DRAFT: Still needs performance evaluation.
This PR reorganizes the
crate::util::object_forwarding
module into a facade, and allows the VM to implement primitive operations of object forwarding as an alternative to the traditional implementation from JikesRVM MMTk.Problem
Some VMs, such as Ruby, do not have spare bits in the header for forwarding bits, but can encode forwarding states ("forwarding not triggered", "being forwarded", and "forwarded") using the type tag (such as the last bits of the
flags
field in the Ruby VM). Such VMs can still put forwarding states and forwarding pointers in object headers, but needs to implement a few object forwarding primitives for mmtk-core in a VM-specific manner.Changes
This PR refactors the
object_forwarding
module to provide an interface that consists of:ForwardingAttempt
struct. It abstracts out the generic work flow of object forwarding, and enforces its methods to be used in a certain way. It also has two variants:WonForwardingAttempt
: contains methods that can only be called when the forwarding attempt "won" the race, including:forward_object
: actually copy the object, and write the forwarding state (bits) and forwarding pointerrevert
: change the forwarding state (bits) back to the state before the forwarding attempt.LostForwardingAttempt
: contains methods that can only be called when the forwarding attempt "lost" the race, including:spin_and_get_forwarded_object
: wait until forwarding is complete or reverted, and return the maybe forwarded object reference.is_forwarded
read_forwarding_pointer
clear_forwarding_bits
(only available in traditional implementation)The methods of the structs and the top-level functions can be routed to the traditional implementation or the VM-specific implementation, controlled by the Cargo feature "vm_forwarding".
When the "vm_forwarding" feature is enabled, the VM binding needs to
ObjectModel::VMForwardingDataType
which is used to hold the old the old type tag after overwriting the type tag to encode the forwarding state.ObjectModel
trait, including:attempt_to_forward
write_forwarding_state_and_forwarding_pointer
revert_forwarding_state
spin_and_get_forwarded_object
is_forwarded
read_forwarding_pointer
And the
ObjectModel::copy
method also takes one extra argument ofObjectModel::VMForwardingDataType
type so that it can restore the type tag of the to-space copy of the object.Performance considerations
When "vm_forwarding" is enabled, the
ForwardingAttempt
struct and its variants may hold the data ofObjectModel::VMForwardingDataType
for the VM binding. But when "vm_forwarding" is enabled, it does not have that field, and it only contains necessary fields for the traditional implementation. In theory, there should be no space or time overhead if "vm_forwarding" is disabled.When "vm_forwarding" is disabled, the VM binding API does not change. This means existing bindings that do not use this feature do not need to be changed.
Performance evaluation
TBD.