Skip to content

Skip val register in ObjectBarrier impl #294

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

Merged
merged 6 commits into from
Dec 5, 2024
Merged

Conversation

wks
Copy link
Contributor

@wks wks commented Dec 4, 2024

MMTkBarrierSetAssembler::store_at calls object_reference_write_post after calling BarrierSetAssembler::store_at. However, BarrierSetAssembler::store_at modifies the val register to compress its value in place. Consequently, object_reference_write_post will see a compressed pointer in the val register.

This PR makes two changes.

Firstly, in MMTkObjectBarrierSetAssembler::object_reference_write_post, we simply set both c_rarg1 and c_rarg2 to 0 before calling the write barrier slow path. We exploit the semantics of the ObjectBarrier that it simply logs the object without looking at the slot or the target. This will fix the assertion error because 0 will be interpreted as a None of type Option<ObjectReference>.

Secondly, we add a bool compensate_val_reg parameter to MMTkBarrierSetAssembler::object_reference_write_post so that if we call it after BarrierSetAssembler::store_at, we can give object_reference_write_post a chance to decompress the compressed oop in the val. This is intended for implementing other barriers introduced in the future that may use the val register, and keep the developers informed that the val register is mutated in BarrierSetAssembler::store_at.

Fixes: #291
Related PR: #293

wks added 5 commits December 3, 2024 14:06
In `MMTkBarrierSetAssembler`, `object_reference_write_post` is called
after calling `BarrierSetAssembler::store_at` which modifies the `val`
register and compresses its value in place.  Consequently,
`object_reference_write_post` will see a compressed pointer in the `val`
register.  We decompress the pointer in the slow path before calling
into MMTk core.
@wks wks requested review from wenyuzhao and qinsoon December 4, 2024 07:58
// Note: If `compensate_val_reg == true && UseCompressedOops === true`, the `val` register will be
// holding a compressed pointer to the target object. If the write barrier needs to know the
// target, we will need to decompress it before passing it to the barrier slow path. However,
// since we know the semantics of `ObjectReference`, i.e. it logs the object without looking at
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you mean "the semantics of object remembering barrier"?

We need to a check to know this is object remembering barrier somewhere in the code. We can get it from https://github.com/mmtk/mmtk-core/blob/a75309373cd301acad473bbb8ea04670facd6e2a/src/plan/plan_constraints.rs#L35, and store the value somewhere for the C++ code to access.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you mean "the semantics of object remembering barrier"?

Oops. That's a typo. I did mean ObjectBarrier.

We need to a check to know this is object remembering barrier somewhere in the code.

The changed code is in mmtkObjectBarrier.cpp which is dedicated to the object remembering barrier. The class MMTkObjectBarrierSetAssembler is only used if get_selected_barrier() in mmtkBarrierSet.cpp returns new MMTkObjectBarrier(); Therefore we don't need to check here, as long as the get_selected_barrier() chooses the right barrier.

@wks wks mentioned this pull request Dec 5, 2024
@wks wks merged commit b448168 into mmtk:master Dec 5, 2024
57 checks passed
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.

ObjectReference is required to be word aligned. addr: 0x8000026
2 participants