Jason Orendorff wrote:
> * Use static tools to replace our uses of nsCOMPtr and friends with > the MMgc > equivalents, and replace nsISupportsWeakReference with MMgc > GCWeakRefs. There are two different uses of weakrefs in our tree: 1) Weak refs used to avoid cycles: A holds a strong-ref to B, which holds a weak ref to A. This is more COM-safe than holding a raw pointer to A. This pattern should simply be replaced by object pointers, which I think means DWB(MyObject*) > * Add thread-safety to MMgc using the Spidermonkey request model. This is the part that has me extremely worried. We would have to propagate the request model throughout all of our XPCOM code, which is a very tricky task. As I understand it, the invariants for requests are: 1) GC references may change only within a request 2) blocking (or long-running) activity should not take place within a request I think that keeping track of whether we're currently in a request would be a major headache. Brendan may kill me for this, but I think that we can and should assert single-threaded behavior for all of JS and "XPCOM/MMGC": that is, MMGC should only be on the main thread. There are necko classes which will want to be accessible via MMGC/XPCOM and also be internally threadsafe, but I believe that they can root themself on the main thread and perform all of their multi-thread networking using an internal threadsafe reference-counting and proxying scheme that is "not XPCOM". > I'll be working on the following bug quite soon, so now is the time to > speak up. > > Bug 393034 - Allocate DOM objects using MMgc > https://bugzilla.mozilla.org/show_bug.cgi?id=393034 Are we sure that we want to get into the "revamp XPCOM" game just to get going with fast-path DOM? The approach you mention in comment 14 approach C makes a lot of sense, without rewriting all of XPCOM: 1) use MMGC for internal DOM references 2) keep using XPCOM for "external" references - XPCOM refs mean the object is rooted 3) teach XPConnect to use MMGC references for DOM objects --BDS _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom
