gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] GC and refcount


From: strk
Subject: Re: [Gnash-dev] GC and refcount
Date: Tue, 22 Dec 2009 20:31:49 +0100

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
> > > address@hidden
> > > 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
> > address@hidden
> > 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
> address@hidden
> 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! 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]