On Sep 4, 12:43 am, Robert O'Callahan <[EMAIL PROTECTED]> wrote: > On Aug 29, 8:32 am, Jason Orendorff <[EMAIL PROTECTED]> wrote: > > * Add thread-safety to MMgc using the Spidermonkey request model. > > Is this compatible with incremental marking? I don't know the details > of MMgc incremental marking but I fear the complexity, and overhead, > of safe concurrent incremental marking. I would hate to eat a > complexity or performance hit for thread-safe memory management that > is very little used.
Here's the post to read: https://mail.mozilla.org/pipermail/tamarin-devel/2007-August/000017.html (under "Maybe incremental is not so bad") Here are the costs: * Incremental marking must happen under a global lock. No other code can be touching GC-managed objects while this happens, just the same as for non-incremental GC. * There's a synchronization cost per call to GC::IncrementalMark, probably negligible in the scheme of things. * There's an additional cost per "write boundary hit". This happens when you assign a pointer to a "white" (unmarked, unqueued) object to a field of a "black" (already marked) object. The white object has to be queued. This should be relatively rare. The cost, when it happens, is that you have to atomically test-and-set a bit (OSAtomicTestAndSet on Mac), which shouldn't be so horrible. > Also, how about MMgc's reference counted objects, would you make those > thread-safe too? That sounds like another performance hit. How about this: split MMgc::RCObject into two classes, MMgc::ThreadSafeRCObject and MMgc::SingleThreadRCObject. Choose one or the other on a per-class basis. This is like what XPCOM programmers already do. I haven't thought this through thoroughly, though. I see (theoretical) performance costs even for SingleThread objects, but not per-refcount and probably acceptable. The bigger problem with MMgc deferred reference counting (DRC) is how to expose it to users. COM's AddRef/Release contract may be annoying, but at least it's simple. Supporting both DRC and straight-up GC means supporting at least 2 totally different memory-management contracts, on a per-interface or per-object basis. It reminds me of the proliferation of open source licenses. How to do this without burdening users is an open question. Suggestions welcome-- DRC is good stuff (and as Tamarin uses it for everything, it's probably unavoidable). -j _______________________________________________ dev-tech-xpcom mailing list dev-tech-xpcom@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-xpcom
