-
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
Improper but "silently succeeding" use of post write barrier #1129
Comments
An alternative solution is that This scheme should work for the generational barrier because the generational barrier is an insertion barrier. It only cares about newly added edges from old to young objects. It should work for the snapshot-at-the-beginning (SATB) barrier, too. It only tries to remember the old target if it exists. It should work for naive RC, too. If there is no old target, there is no object to decrement its RC; if there is no new target, there is no object to increment its RC, either. But if we want to implement deferred RC, we need an object-remembering barrier. It needs to keep a snapshot of the object and put the object reference in the modbuf in the pre-barrier even if we are updating a field from NULL to a target, so that we can apply the right number of inc and dec operations at the next GC. |
Change the target type of write barrier functions to `Option<ObjectReference>`. This allows VM bindings to use the write barrier API when storing NULL references or non-references values to slots. Fixes: mmtk#1129
Change the target type of write barrier functions to `Option<ObjectReference>`. This allows VM bindings to use the write barrier API when storing NULL references or non-references values to slots. Fixes: #1129
This is a sub-problem of #1038 which we decided to postpone after the MEP for removing
ObjectReference::NULL
(#1043).MMTk's write barrier functions take
target: ObjectReference
as parameter. For example,With #1043 merged, this form no longer works if
target
isNULL
or any other non-reference values. But real-world programs may overwrite a field previously holding an object reference with NULL or a non-reference value.However, all bindings are still working. That's because they transmute 0 to
ObjectReference
in C/C++ and pass them to Rust. Currently, the object-remembering write barrier simply ignores theslot
and thetarget
fields, so it is unaware that theObjectReference
variable is holding an illegal value. But we have to acknowledge that it is a bug and should be fixed.We can simply change
target
toOption<ObjectReference>
, withNone
representing a deleted edge.However,
object_reference_write
will no longer work iftarget
isNone
because MMTk core cannot writeNULL
or non-reference values to the slot.The text was updated successfully, but these errors were encountered: