Replying to several messages/thoughts at once: 1. Losing the cycle collector's support for other languages is necessary to get C++ and JS on a better footing -- a shared GC heap. But the idea and even code could be harvested for use by other language runtimes, since we will still face uncollectable cycle hazards interfacing Java, Python, etc. to C++ and JS.
2. Other languages in Mozilla 2 should prefer to integrate at the VM level, on Tamarin. See IronMonkey. 3. Jonas's first point: We should avoid making non-refcounted XPCOM classes be GC-objects without good evidence doing so wins in time and space overhead. But (separate topic/thread) we hope to use std::string and the like more where possible, and use Taras's elsa-based tools to write the mega-patches for us. 4. Jonas's second point: MMgc needs to become more conservative about interior objects. Currently it does not back up from a pointer to an interior (via MI or explicit member embedding) to the outermost (allocation) object. 5. David's first point: the request model is already followed (file bugs if you can) in Mozilla code (this was not always so). We aim to keep it, but it does not mean there is any thread-safety cost imposed on GC'ed objects. Only that the embedding must begin, end, suspend, resume, and yield requests appropriately (could use some static analysis help here too). The JS objects that SpiderMonkey creates already use the request model to do optimistic lock-free synchronization, so no change there. And we are not imposing such synchronization on other objects for Mozilla 2, as far as I can see. /be _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom
