Closed Bug 737195 Opened 8 years ago Closed 8 years ago
GC: missing barrier on JSFunction::atom
We appear to trace through JSFunction::atom. We only ever initialized it, so we don't need incremental barriers on it, but we do need generation barriers here.
Does this make sense? It would be less code to just trigger the atom post barrier manually in the two places where it is needed, but this way seems cleaner.
I think this misses the barrier in the js_XDRAtom case. The right way to handle that is similar to what we do with script in that function. Basically, define a local variable |atom|. In the encode case, set it to fun->atom. In the decode case, set it to NULL. Then pass &atom to js_XDRAtom. Later, in the JSXDR_DECODE section, call fun->atom.init(atom). Related to this, I think that the fun->setScript(script) statement can be changed to initScript.
Attachment #607341 - Flags: review?(wmccloskey) → review+
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla14
You need to log in before you can comment on or make changes to this bug.