You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
`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](#291) 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
/// `compensate_val_reg` is true if this function is called after `BarrierSetAssembler::store_at` which compresses the pointer in the `val` register in place.
0 commit comments