Open qinsoon opened 3 years ago
For example, I encountered a case where the
get_next_mutator()
is not implemented properly. Because of this, the preparation for each mutator is not called at all, and the mutator does not have its thread local state reset for the GC, which leads to a strange error when the mutator tries to allocate after GC. We should have some sort of assertions for this, like check the number of mutators in GC preparation, and file a warning if the number is 0.
We should find a way to assert if a mutator is properly reset in the GC. We would have the same issue if we miss any mutator.
MMTk core requires the VM binding to implement the
VMBinding
trait. However, if they do not implement the traits correctly, or sometimes miss a few methods (and return invalid results instead), MMTk core would just fail strangely, and does not give any useful warning or debug message.For example, I encountered a case where the
get_next_mutator()
is not implemented properly. Because of this, the preparation for each mutator is not called at all, and the mutator does not have its thread local state reset for the GC, which leads to a strange error when the mutator tries to allocate after GC. We should have some sort of assertions for this, like check the number of mutators in GC preparation, and file a warning if the number is 0.I think we would like to go through the
VMBinding
trait, and try have assertions for each method if possible. This could help the binding implementer greatly.