Benjamin Smedberg wrote: > > The list of tasks to accomplish this is at least:
Commenting here on things that concern automation. > > * Add the request model threadsafety to MMGc > * Give MMGc the ability to recognized "inner" pointers to objects > * Identify request start/end points in the codebase (blocking activity) > * Ensure (how?) that existing locking mechanisms for threadsafe code won't > deadlock with GC I don't see better way to do this other than experimentation. Once we discover bugs and unsafe usage patterns we can start thinking about hunting those down using static analysis tools. > * Rewrite XPCOM addref/release handling > ** Remove or stub out getter_AddRefs, already_AddRefed, and other helper > classes > ** Make member-comptrs call/be DWB Can rewrite these. Only question is, do these have to be macros? They make rewriting things later more painful than needed. > ** Make stack-comptrs raw pointers Can detect those easily enough with static analysis. > ** Fix some COM-holding utility classes > *** nsCOMArray We should probably be switching away from moz-specific containers to stl ones. I could probably rewrite these. > *** nsInterfaceHashKey > *** nsInterfaceHashtable > ** Identify XPCOM weakrefs that can be GCRefs This can't be done completely automatically. Once we identify a common pattern to look for, then automation can be considered. > ** Rewrite the other XPCOM weak-references into GCWeakRefs I'm not sure if the concepts map directly. Shouldn't most weak references become gc-managed pointers? Taras _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom
