On Aug 28, 6:07 pm, mhammond <[EMAIL PROTECTED]> wrote: > 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,
MMgc is conservative. So long as Python allocates memory to be scanned for pointers to MMgc allocations using MMgc's malloc wrapper, MMgc will find these pointers. You need an MMgc GCRoot subclass (one or more, perhaps at most one per other language implementation) to root all the Python objects that are not (or not guaranteed to be) pointed at by pointers in memory MMgc scans. > 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. That would be bad, so let's not ;-). > Deep hacks specific to Python and MMgc might be possible, > but that still screws Perl, etc. Perl is not helped much by PyXPCOM, right? How does this differ with XPCOM-on-MMgc? > 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. This is not the way, agreed. > 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 - It's easier because MMgc is conservative -- but I should add that it's harder if MMgc is used in incremental mode, because you need to impose a write barrier on Python. > 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) GC-to-GC cycle collection is easier than refcount cycle collection. See http://www.cs.cmu.edu/~roc/HetGC.html (I hope this is sound -- I never did proofs ;-) and Parley from IBM research, where the best link I can find is: http://researchweb.watson.ibm.com/vee04/video.html#grove > 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. Precisely -- wherefore IronMonkey. > So maybe we are asking the wrong question > - what is the future of XPCOM itself, not just its memory management? And indeed Jason posted a separate thread on that topic. See you there :-). /be _______________________________________________ dev-tech-xpcom mailing list dev-tech-xpcom@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-xpcom
