Brendan Eich wrote: > Jonas Sicking wrote: >> Related to the above, should we attempt to use incremental GC. From what >> I understand this should be entierly possible with MMgc. However it >> requires that all pointers use special smart-pointers. Including >> pointers that are currently raw-pointers. This seems a little bit >> scary and easy to forget, but might be very nice for performance. > > Raw pointers should be banned in incremental GC settings. We can use > static analysis to enforce this. > > And anyway, we really do need to understand ownership at every edge in > the graph. Right now, a raw pointer is a giant question mark that should > raise alarms about either manual-over-refcounted leak bugs, or else > manually-dropped-early or just plain-old-raw-weak-pointer and therefore > dangling-pointer, exploitable bugs.
Many of our raw pointers exist solely to avoid cycles, like the nsNodeInfoManager::mDocument <-> nsDocument::mNodeInfoManager cycle where the first is a raw pointer but is nulled out when the nsDocument is deleted. In this case both pointers should use normal write barriered pointers. In other cases we use raw pointers in order to store extra bits. For example nsINode::mParentPtrBits where we use the two lower bits to store data. Here I suspect we could probably create some sort of wrapper class that creates a write barrier, but still allows the two lower bits to be used. Yet a third example is nsINode::mFlagsOrSlots which sometimes stores a bitfield and sometimes stores a pointer. This situation is approximately the same as the previous one, possibly with exception that the wrapper class needs to be able to return a bitfield in addition to a pointer. / Jonas _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom
