-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Let the VM customize object forwarding implementation #975
base: master
Are you sure you want to change the base?
Conversation
This reverts commit 6112020.
Formatting. Don't link to private items.
Preliminary experiments show that this change allows the Ruby binding to trigger fewer GCs (and have lower STW time) at tighter heap sizes, likely because of the heap space saved by eliminating the on-the-side forwarding bits. At higher heap sizes (3x min heap size or larger), the difference between in-header and on-the-side forwarding bits becomes less significant. |
I ran lusearch on shrew.moma, comparing build1 (master) and build2 (this PR), with no change in mmtk-openjdk, with 2.5x min heap size, 40 invocations. The result is, the overhead in STW time is low (less than 1% for most plans except Immix), but not zero. I think this abstraction should not have any overhead, and I'll look into it later. Since we are not prioritising refactorings like this for now, I'll postpone this PR until 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.