Closed Bug 714642 Opened 13 years ago Closed 12 years ago

Figure out some way to optimize nsXPCWrappedJS traversing

Categories

(Core :: XPConnect, defect)

12 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 720686

People

(Reporter: smaug, Assigned: smaug)

References

(Blocks 1 open bug)

Details

Attachments

(2 files, 3 obsolete files)

In some cases we traverse lots of nsXPCWrappedJS objects.
We should try to do less or be faster.
*If* my testing is correct, in many cases about 65% of WrappedJS objects are certainly alive.
Would be great to be able to skip that.
Attached patch patch (obsolete) — Splinter Review
Something like this.
Didn't seem to leak at least in simple tests, but let's see what
tryserver says
https://tbpl.mozilla.org/?tree=Try&rev=44772bdb3013
Um, is the patch all wrong :/
Comment on attachment 585330 [details] [diff] [review]
patch

Ok, this doesn't make sense, but something similar could.
Attachment #585330 - Attachment is obsolete: true
So, I want to be able to mark WrappedJS object certainly alive.
Fortunately nsXPCWrappedJS has plenty of spare bits left.
Attached patch WIPSplinter Review
On top of other stuff I have
OS: Linux → All
Hardware: x86_64 → All
Blocks: 698919
Attached patch patch (obsolete) — Splinter Review
Something like this.
DOM code, for example, can then set the generation. This can be used to
optimize for example event listener traversing.
Assignee: nobody → bugs
Attachment #586507 - Flags: review?(mrbkap)
Blocks: 716502
Blocks: 716501
Can we just skip these altogether?  We need to add all C++->JS edges so that we hold alive everything from JS.  To catch cross-compartment cycles, we only need either all C++->JS or all JS->C++ edges.
Blocks: 716598
No longer blocks: 698919
(In reply to Andrew McCreight [:mccr8] from comment #8)
> Can we just skip these altogether?
You mean removing the whole
for (XPCRootSetElem *e = mWrappedJSRoots; e ; e = e->GetNextRoot()) {
         nsXPCWrappedJS *wrappedJS = static_cast<nsXPCWrappedJS*>(e);

?
Perhaps. Blake, Peter?

The patch is certainly safer option, since it would be used only in those cases when
the object is certainly owned by something black.
Yes, that's what I meant.  It sounds like this is actually useful in either case, because it will squash things being held by black JS.  We can investigate the more radical option in another bug.
Comment on attachment 586507 [details] [diff] [review]
patch

I don't understand the XPCWrappedJS stuff well enough to contribute here. Hopefully peterv can, though.
Attachment #586507 - Flags: review?(mrbkap) → review?(peterv)
Err, that's the wrappedJS *traversal* stuff.
Comment on attachment 586507 [details] [diff] [review]
patch

I have a better plan for this.
Attachment #586507 - Flags: review?(peterv)
Attached patch patch (obsolete) — Splinter Review
Sorry for the -U 1, but I just manually cut the patch from a larger patch.

http://mxr.mozilla.org/mozilla-central/source/js/xpconnect/src/XPCJSRuntime.cpp#579
Attachment #586507 - Attachment is obsolete: true
Attachment #590373 - Flags: review?(peterv)
Blocks: 705582
Attached patch v3Splinter Review
Oops, previous patch was  missing the #include.
Attachment #591021 - Flags: review?(peterv)
Attachment #591021 - Flags: feedback?(continuation)
Attachment #590373 - Attachment is obsolete: true
Attachment #590373 - Flags: review?(peterv)
Comment on attachment 591021 [details] [diff] [review]
v3

This got merged to the generic xpc patch
Attachment #591021 - Flags: review?(peterv)
Attachment #591021 - Flags: feedback?(continuation)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: