As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact
Last Comment Bug 720926 - Incremental GC needs read barrier on xpc_UnmarkGray
: Incremental GC needs read barrier on xpc_UnmarkGray
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: All All
: -- normal (vote)
: mozilla13
Assigned To: Bill McCloskey (:billm)
: Jason Orendorff [:jorendorff]
Depends on:
  Show dependency treegraph
Reported: 2012-01-24 19:03 PST by Bill McCloskey (:billm)
Modified: 2012-02-23 09:49 PST (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch (2.24 KB, patch)
2012-01-24 19:03 PST, Bill McCloskey (:billm)
igor: review+
bent.mozilla: feedback+
Details | Diff | Splinter Review

Description User image Bill McCloskey (:billm) 2012-01-24 19:03:39 PST
Created attachment 591350 [details] [diff] [review]

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 User image Ben Turner (not reading bugmail, use the needinfo flag!) 2012-01-24 22:53:24 PST
Comment on attachment 591350 [details] [diff] [review]

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 User image Igor Bukanov 2012-01-25 01:27:19 PST
(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 User image Bill McCloskey (:billm) 2012-02-23 09:49:49 PST
This landed along with incremental GC.

Note You need to log in before you can comment on or make changes to this bug.