/be
This analysis doesn't sound hard, but you're going to end up with lots of
false-positives: i.e. all the necko classes, which certainly have
member-comptrs but can't be cycle-collected because they are multi-threaded
objects.
I don't think we are or should be trying to cycle-collect every XPCOM object
that has strong refs (even just the single-thread ones)... doing so would
require lots and lots of additional classes be cycle-collected: you'd have
to add many services which already have application lifetime, so the cycle
collector would only be a benefit in cleaning up shutdown cycles, if at all.
Some examples that come immediately to mind:
* observer service
* prefservice
* appstartup
cc'ing dev.platform in
--BDS
This is no objection, it's a trivial tweak to my (very non-
algorithmic) sketch! ;-)
Of course, we have some bogo-threadsafe XPCOM classes that are main-
thread only and should be considered in the scan. Never said it was
easy, but the decision tree to reduce false positives beckons already.
/be
To get fewer false positives we could only warn for members that hold
references to objects that participate in cycle collection.
/ Jonas
FWIW, I haven't found the false positives to be too troubling. Just
have to audit things.
- Rob