Benjamin Smedberg wrote: > mhammond wrote: > >> Yes, this will be a challenge. I can't picture how dropping refcounts >> would work in the general case with Python. The XPCOM objects exposed >> by Python can be made a GCObject - but I'm not sure how we would >> integrate the rest of the Python universe - eg, assuming we have an >> arbitrary number of Python objects holding pointers to xpcom objects, >> I'm not sure how we would tell the GC about all such references - and > > Can't you just root them while python holds the external references?
You can root at some cost. But roots aren't cheap, and IIRC Mark used delegated Python incref/decref to call XPCOM AddRef/Release directly -- cheaper and in sync with Python's ref-counting with background GC memory management. And with roots, you can still have cycles between heaps (but these were not addressed by PyXPCOM, and as dbaron noted, the XPCOM cycle collector's stubs for PyXPCOM need to be fleshed out and tested). Roots are not the answer for interior nodes. With SpiderMOnkey, delegated trace (formerly mark) and finalize class hooks help. But any two memory managers colliding, you want cheaper-than-global-root edge tracing, and for leak-proofing you must have to do something further to deal with cycles. Life is better with a single GC, which is why we are unifying C++ and JS on top of MMgc for Mozilla 2, and why we are supporting IronMonkey to add other languages on top of a common memory manager and JITting VM (along with memory safety and other benefits as motivation, in addition to avoiding multi-heap integration and cycle-breaking hassles). /be _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom
