Jason Orendorff wrote: > All threads will be in a request all the time, except when doing > blocking I/O or CPU-bound, non-GC-touching stuff. You'll have to > suspend the request before doing that kind of thing, and resume it > afterwards. I imagine we'll have a C++ object that knows how to do > this. (Like nsAutoLock. "nsAutoSuspendRequest", maybe.) > > Finding those places would be the only hard part. But if you miss one, > it should be *real* easy to spot and debug. Firefox will seem to hang. > You'll attach a debugger, and all threads will be sitting in > MMgc::waitForGC except for one, which will be blocked on DNS or > compositing video buffers.
ok, you have me mostly convinced... let's proceed under the general assumption that this is what we want to do. To accomplish this, we're going to have a lot of different things going on: The list of tasks to accomplish this is at least: * Add the request model threadsafety to MMGc * Give MMGc the ability to recognized "inner" pointers to objects * Identify request start/end points in the codebase (blocking activity) * Ensure (how?) that existing locking mechanisms for threadsafe code won't deadlock with GC * Rewrite XPCOM addref/release handling ** Remove or stub out getter_AddRefs, already_AddRefed, and other helper classes ** Make member-comptrs call/be DWB ** Make stack-comptrs raw pointers ** Fix some COM-holding utility classes *** nsCOMArray *** nsInterfaceHashKey *** nsInterfaceHashtable ** Identify XPCOM weakrefs that can be GCRefs ** Rewrite the other XPCOM weak-references into GCWeakRefs Other random notes/questions: What are the rules for objects with finalizers? Is the finalize method allowed to touch other objects? Presumably these objects may have already been finalized, right (or else you'd end up with finalization cycles)? Right now many objects are going to have to be finalized, because they contain string members or do real work in their constructor. We should discuss the pros/cons of making strings GCthings, or even sharing the tamarin string type with XPCOM. We should also automatically identify destructors that do "real" work to see if we can remove that work, or if the work is even safe to do when the target object may have already been finalized. Because the main thread is always non-blocking by design, it would naturally never exit its request. This is probably ok as long as we force GC to always take place on the main thread. If GC gets triggered on a worker thread, that thread would block forever. Alternately we could exit/reenter the request every time we process the main event queue. --BDS _______________________________________________ dev-tech-xpcom mailing list dev-tech-xpcom@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-xpcom
