768099 - move XPConnect cycle collector code out of nsXPConnect

Status: RESOLVED DUPLICATE of bug 882162

(Core :: XPConnect, defect)

Description

[Andrew McCreight [:mccr8]]

With bug 616262 in place, there's no need for most of the cycle collector code needed in XPConnect to live in nsXPConnect.cpp proper.  Things I'd like to move out include nsXPConnectParticipant and JSContextParticipant.  After bug 754495, there will also be CompartmentParticipant.  I'm not sure if these should each live in their own file, or if we could just have some kind of grab-bag XPCCycleCollector.cpp kind of file.

Comment 1

[Andrew McCreight [:mccr8]]

The cycle collector has a lot of infrastructure for tracing JS objects that lives in XPConnect, but it is mostly dependent only on JSAPI.  If we're using the cycle collector in workers, we'll have to factor this out somehow.

Roughly speaking, this means the part of XPConnect that implements nsCycleCollectionJSRuntime.

The trickiest aspect of this that I can think of offhand is that the code that looks for C++ pointers in JS objects has a case for XPConnect stuff, in addition to new DOM bindings.

There's also at least one callback we register with the JS runtime that will need to be done in a worker, too, but maybe that can happen in another bug.