Closed Bug 640852 Opened 9 years ago Closed 9 years ago

can we remove the atom-compartment-avoidance gunk from string marking?

Categories

(Core :: JavaScript Engine, defect)

defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: luke, Assigned: luke)

References

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 file)

Attached patch rmSplinter Review
Bill and Gregor couldn't think of any reason it was bad to mark atoms in the atomCompartment during a per-compartment gc.  Removing the gunk not only removes a tidy bit of code, bit makes a simple marking microbench (the one in bug 616562 comment 0) 5% faster.
Attachment #518609 - Flags: review?(anygregor)
Comment on attachment 518609 [details] [diff] [review]
rm

Can we leave the part where we assert that all "chained" strings are in the same compartment or end in the atomsCompartment?
Attachment #518609 - Flags: review?(anygregor) → review+
Oh, I meant to comment on this:

My reasoning for nixing those is that the "same or atoms compartment" property is asserted by js_ConcatStrings which is the only way to get a rope, so all this really seems to be guarding against is some bizarre memory corruption.  I.e., I don't these asserts would catch compartment misuses since those would (and do) hit earlier (hopefully much earlier now that assertSameCompartment checks strings).
http://hg.mozilla.org/tracemonkey/rev/4a73b3a12f30
Whiteboard: fixed-in-tracemonkey
http://hg.mozilla.org/mozilla-central/rev/4a73b3a12f30
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.