-
Notifications
You must be signed in to change notification settings - Fork 78
Description
I think the spin_and_get_forwarded_object() function [1] itself is incorrect. It shouldn't panic if the forwarding bits are not FORWARDED. Consider this [2] case:
let forwarding_status = ForwardingWord::attempt_to_forward::<VM>(object);
if ForwardingWord::state_is_forwarded_or_being_forwarded(forwarding_status) {
// We've lost the forwarding race as some other thread has set the forwarding word
ForwardingWord::spin_and_get_forwarded_object::<VM>(object, forwarding_status)
} else if self.is_marked(object, self.mark_state) {
// We won the forwarding race but object is already marked so we clear forwarding word and return un-moved object
ForwardingWord::clear_forwarding_bits::<VM>(object);
object
} else {
// We won the forwarding race; actually forward and copy the object if it is not pinned
[ ... ]
}But we can get interleaving such that one thread has lost the race and the other has won but it doesn't move the object. Let's assume the second thread clears the bits. We then trigger the panic in the first thread since it is expecting the forwarding bits to be FORWARDED.
I note that the JikesRVM mmtk implementation for spinAndGetForwardedObject() does not panic if the forwarding word is not FORWARDED [3]. + JikesRVM mmtk's implementation of Immix has a bunch of debug assertions which check for this exact case [4] which Rust mmtk's implementation of Immix does not have.
[1]: https://github.com/mmtk/mmtk-core/blob/master/src/util/object_forwarding.rs#L54-L73
[2]: https://github.com/mmtk/mmtk-core/blob/master/src/policy/immix/immixspace.rs#L392-L416
[3]: https://github.com/JikesRVM/JikesRVM/blob/master/MMTk/src/org/mmtk/utility/ForwardingWord.java#L78-L88
[4]: https://github.com/JikesRVM/JikesRVM/blob/master/MMTk/src/org/mmtk/policy/immix/ImmixSpace.java#L529-L536