Skip to content
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

Draft
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

wks
Copy link
Collaborator

@wks wks commented Oct 12, 2023

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:

  • The 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 pointer
      • revert: 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.
  • Some top-level functions, including:
    • 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

  • Define a VM-specific data type ObjectModel::VMForwardingDataType which is used to hold the old the old type tag after overwriting the type tag to encode the forwarding state.
  • Implement some primitive operations in the 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 of ObjectModel::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 of ObjectModel::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.

  • Test the OpenJDK binding. It should have exactly the same perforamance.
  • Test the Ruby binding. It should be faster, or at least be as fast as before. It no loner needs to use on-the-side forwarding bits.

@wks
Copy link
Collaborator Author

wks commented Nov 1, 2023

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.

@wks
Copy link
Collaborator Author

wks commented Nov 2, 2023

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.

Plotty link: https://squirrel.anu.edu.au/plotty/wks/noproject/#0|shrew-2023-11-01-Wed-081208&benchmark^build^invocation^iteration^mmtk_gc&GC^time^time.stw&|10&iteration^1^4|20&1^invocation|30&1&benchmark^mmtk_gc&build;build1|41&Histogram%20(with%20CI)^build^mmtk_gc&

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant