Created attachment 591350 [details] [diff] [review] patch Let's say you have a JS object, and if you did a GC at time t0, it would get marked gray. But instead you start an incremental GC at time t0. Now, before the GC finishes, you access the JS object through XPConnect and create a reference to it from some black JS object. UnmarkGray will not be called on the object when it's accessed from XPConnect, because it's not gray (it's white). Eventually it will be colored gray, assuming it's still accessible from the gray roots. The issue here is that pointers from XPConnect are sort of like weak pointers, and so we need read barriers on them. This patch adds that barrier. I considered changing the name of UnmarkGray, but I couldn't come up with something better. The function is still basically doing the job of converting the object from gray to black. It's just that during an incremental GC, it does it in a different way. Ben, I'm asking for feedback so that someone in XPConnect knows about this change.
Comment on attachment 591350 [details] [diff] [review] patch The description and the patch make sense to me! One question, we recursively flood obj black if it is gray, does js::IncrementalReferenceBarrier work like that too?
(In reply to ben turner [:bent] from comment #1) > One question, we recursively flood obj black if it is gray, does > js::IncrementalReferenceBarrier work like that too? Yes - the function ensures that the GC will eventually mark as black the object and anything reachable through it.
This landed along with incremental GC.