Benjamin Smedberg wrote: > 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.
Jason addressed the request model fear. Main thread code can't block indefinitely for i/o already, so the only request suspend points that I can see right now are * lengthy, non-GC-graph-mutating computations; * file i/o that's "blocking, but fast", yet not fast enough for us to wish to stay in a request; * required deadlock-with-the-GC avoidance not handled by the request model itself. > 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". More than Necko classes are at stake. We know of AllPeers and Songbird MT XPCOM usage, and I believe Joost too uses XPCOM with shared memory threads. I do not propose to make all such consumers of XPCOM rewrite their code for Mozilla 2, even though it could turn out that everyone agrees on doing that, for good wins in reasonable timeframe. Proceeding incrementally, removing ref-counting from XPCOM and moving it to GC, seems a much better approach, since we don't know all the costs and benefits, and how they trade off for different platform clients. >> 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 This is more work because it bridges two memory managers. It requires the cycle collector still. We should try to cut to the chase and move XPCOM to MMgc. /be _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom
