A posible solution to this problem is having intrusive_ptr_add_ref(const ref_counted* o) and intrusive_ptr_release(const ref_counted* o)
NEVER dereference 'o' but rather ask the GC to manage the reference count. The GC might keep a map of managed resources and do nothing if they are no more in the list. Only thing to take care of in this case would be ensuring that the objects-to-be-deleted won't be really deleted (freed) until the intrusive_ptr they contain are reset, which means adding a method to every objects who may contain references to GcResources to use for 'clearing' all those references before destruction. --strk; On Mon, Dec 21, 2009 at 06:49:55PM +0100, strk wrote: > Ehm.... for the record, the case to think about is the unreachable > chain of GcResources circularly referencing each-other trouh this > "smart pointer". > The GC would delete the resources, so the "smart pointers" would > NOT be able to access the actual referee object w/out memory violations. > > We'd then need a way from the GC to signal all smart pointers about > this condition. Chances are weak pointers would help here, but I've no > experience with that (will do some research). > > --strk; > > On Mon, Dec 21, 2009 at 06:32:12PM +0100, strk wrote: > > I've created a new shared branch for the GC work: > > bzr branch http://bzr.savannah.gnu.org/r/gnash/branches/gc > > > > The GC version in the branch allows "manual" deletion of GcResource > > objects by having GcResource destructor remove self from the GC-managed > > list. Cost of this is + sizeof(std::list::iterator) per GcResource. > > Removal from the std::list runs in constant time. > > > > Now that we have that possibility, adding a ref-count in GcResource > > would let us remove earlier any object not containing circular refs. > > Only trouble would be making sure intrusive_ptrs for GcResource > > are properly used within the whole codebase. > > The SafeStack implementation would need to stop keeping as_value > > alive in order for memory reduction to be noticeable. > > > > --strk; > > > > > > On Sat, Dec 19, 2009 at 12:17:43PM +0100, strk wrote: > > > Here's another idea to reduce memory use. > > > We could mix refcount and gc for the GcResources > > > so that in absence of circular refs we'll release > > > them sooner. > > > > > > The additional overhead would be: > > > - refcount management (per reference) > > > - GC list management (per object) > > > > > > Implementation: > > > - manage GcResources with intrusive_ptr<> > > > like others. > > > - Tweak add/drop refs for GcResource in libbase/smart_ptr.h > > > - Tweak GcResource to add refcount and signal GC > > > about being removed. > > > > > > --strk; > > > > > > Free GIS & Flash consultant/developer () ASCII Ribbon Campaign > > > http://foo.keybit.net/~strk/services.html /\ Keep it simple! > > > > > > > > > _______________________________________________ > > > Gnash-dev mailing list > > > [email protected] > > > http://lists.gnu.org/mailman/listinfo/gnash-dev > > > > -- > > > > Free GIS & Flash consultant/developer () ASCII Ribbon Campaign > > http://foo.keybit.net/~strk/services.html /\ Keep it simple! > > > > > > _______________________________________________ > > Gnash-dev mailing list > > [email protected] > > http://lists.gnu.org/mailman/listinfo/gnash-dev > > -- > > Free GIS & Flash consultant/developer () ASCII Ribbon Campaign > http://foo.keybit.net/~strk/services.html /\ Keep it simple! > > > _______________________________________________ > Gnash-dev mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/gnash-dev -- Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
