720926 - Incremental GC needs read barrier on xpc_UnmarkGray

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: 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 1

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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?

Comment 2

[Igor Bukanov]

(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.

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

This landed along with incremental GC.