Global nsICycleCollector service

designer handbag kate replica spade wholesale replica coach handbag coach signature replica handbag wholesale aaa replica handbag aaa chloe handbag replica aaa grade handbag replica handbag lv replica wholesale hermes handbag replica cheap replica handbag cheap replica chanel handbag cheap replica coach handbag cheap wholesale replica handbag cheap designer replica handbag wholesale replica chloe handbag chloe handbag paddington replica chloe designer handbag replica fendi replica handbag fendi and gucci replica handbag wholesale designer replica handbag replica designer handbag at wholesale prices wholesale replica handbag handbag wholesale replica watch wholesale replica lv handbag replica handbag wholesale price replica chanel handbag replica designer handbag chanel discount chanel handbag replica handbag louis replica theda vuitton handbag louis replica shopping vuitton bag image louis mirror replica vuitton bag designer diaper replica bag dior replica bag christian dior replica bag hermes replica bag birkin hermes replica bag burberry replica

== Problem overview ==When multiple XPCOM objects form a cycle but are otherwise disconnected from any live roots (pointers not embedded in XPCOM objects that a thread can find transitively from its static and local variables, e.g. local nsCOMPtr variables) it is considered a garbage cycle. Currently XPCOM cannot collect garbage cycles. This is a proposal to produce a collector for such cycles.Common sources of garbage cycles in XPCOM appear to be cycles between javascript objects and browser objects, particularly DOM objects.== Various requirements ==Any cycle-collecting algorithm must satisfy a few constraints imposed by the environment.* Some objects will never be upgraded to participate in cycle collection. The mechanism must not break if it is applied to only a subset of the objects in the graph.* XPCOM objects cannot generally be freed in any consistent fashion, such as by calling "operator delete". Objects should be made to "self destruct" by having all their incoming edges drop.* Adding gratuitous new interfaces, vtables, or pointer state is probably too expensive.== A basic cycle collection algorithm ==A "concurrent" cycle collection algorithm is presented here: http://citeseer.ist.psu.edu/paz03fly.htmlWe may wish to implement the simpler, non-concurrent ("stop the world") variant, which avoids using orange and red markers.== A sketch of an implementation in XPCOM ==* nsICycleCollector.idl* nsIClassInfo2.idl* nsCycleCollector.cpp* nsISupportsImpl.h changesSome notes on the implementation:* The implementation requires that each participating XPCOM class implement nsIClassInfo2. The two methods on this interface must be correct: it is better not to implement nsIClassInfo2 than to implement it wrong.** unlink(obj) should disconnect all outgoing XPCOM references held by obj.** traverse(obj,refcount,childcount,children) should return the refcount for obj, as well as the count and an array of outgoing XPCOM references from obj.* An object implementing nsIClassInfo2 should also use the NS_IMPL_CYCLE_COLLECTING_* macros in the nsISupportsImpl header; these implementations hook the appropriate refcount operations to communicate with the global cycle collector.* The implementation commandeers a single bit from the refcount stored in nsAutoRefCnt. This is not strictly necessary, but should cut down significantly on pointless traffic to the cycle collector.* The global cycle collector service is kept as a singleton pointer in nsAutoRefCnt. This poses potential problems during shutdown. Advice on how to handle this safely would be appreciated.