On Aug 29, 9:46 am, "L. David Baron" <[EMAIL PROTECTED]> wrote: > Jason Orendorff wrote:
> > * Delete the cycle collector. > > Are we dropping the multi-language aspects of the platform (introduced > in this milestone, at considerable effort > inhttps://bugzilla.mozilla.org/show_bug.cgi?id=255942)? Or is there a > good way for python to use MMgc as well? > > (That said, the python stuff hasn't caught up with the cycle collector, > and would probably leak a lot if it were used as intensively as we use > JS, so I'm not sure how seriously we should take it.) 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 without that knowledge, the GC would cleanup objects that are referenced. Deep hacks specific to Python and MMgc might be possible, but that still screws Perl, etc. Building a new version of Python that uses MMgc might be possible but (a) it might not be and (b) every Python extension module would also need to either (likely) change or (if we are extremely lucky) be rebuilt. To summarize, I see that having an external language integrate with such MMgc is no more - and no less - difficult than integrating with the existing spidermonkey GC - and I'm not aware of anyone who believes that is feasible in either the general case, or even just the specific cases on the table (ie, existing languages with xpcom bindings) On the other side of the coin though, the future may be closer to something like .NET, where languages like Python are reimplemented on top of a new VM - in which case the GC comes "for free" - but in such a world xpcom doesn't make as much sense anyway - the VM itself can make cross-language calls. So maybe we are asking the wrong question - what is the future of XPCOM itself, not just its memory management? Cheers, Mark _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom
