-
Notifications
You must be signed in to change notification settings - Fork 39
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
Conversation
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.
// 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
MMTkBarrierSetAssembler::store_at
callsobject_reference_write_post
after callingBarrierSetAssembler::store_at
. However,BarrierSetAssembler::store_at
modifies theval
register to compress its value in place. Consequently,object_reference_write_post
will see a compressed pointer in theval
register.This PR makes two changes.
Firstly, in
MMTkObjectBarrierSetAssembler::object_reference_write_post
, we simply set bothc_rarg1
andc_rarg2
to 0 before calling the write barrier slow path. We exploit the semantics of theObjectBarrier
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 aNone
of typeOption<ObjectReference>
.Secondly, we add a
bool compensate_val_reg
parameter toMMTkBarrierSetAssembler::object_reference_write_post
so that if we call it afterBarrierSetAssembler::store_at
, we can giveobject_reference_write_post
a chance to decompress the compressed oop in theval
. This is intended for implementing other barriers introduced in the future that may use theval
register, and keep the developers informed that theval
register is mutated inBarrierSetAssembler::store_at
.Fixes: #291
Related PR: #293