gnash-dev
[Top][All Lists]
Advanced

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

Re: [Gnash-dev] GC branch plan and call for help


From: strk
Subject: Re: [Gnash-dev] GC branch plan and call for help
Date: Fri, 11 Jun 2010 12:42:00 +0200

I've shared my current branch (code name "segfaults++") here:

  https://code.launchpad.net/~strk/+junk/gnash-gc

Have to admit I completely forgot the shared branch on savannah
not sure it has any nice things for me.

The current focus on the launchpad branch is setting up
the infrastructure to let intrusive_ptr delete collectables.

When activated (it is activated right now) it'll make
intrusive_ptr_add_ref(GcResource*) increment a new counter
added to the GcResource and intrusive_ptr_release(GcResource*)
request refcount decrement to the GC (accessing trough the
singleton).

The GC will NOT dereference the GcResource if it's in his
sweeping phase, as that would mean any reference dropping
would be coming from other unreachable objects being sweeped
and thus the being-released pointer would be pointing to
an already-condamned resource.

Resources deleted by ref-count when still reachable will
trigger segfaults on the GC mark phase. This will be
the biggest change required to the codebase (ensuring
appropriate intrusive_ptr use ).

But again, before going there, which I'd like to think
more about (have GC keep a ref?). The current problem
seems to be segfaults due to intrusive pointers surviving
GC lifetime. GC gets destroyed as part of gnash::clear()
and it looks like at that time other intrusive_ptr on
GcResource are around, and triggering on exit.

DO NOT USE THIS BRANCH IF NOT TO HELP DESIGNING THE MECHANISM

An empty SWF file is enough to deliver you segfaults.

PS:
 HINT: bzr push lp:~<username>/+junk/<branchname>

--strk;

On Wed, Dec 23, 2009 at 05:19:28PM +0100, strk wrote:
> Alright hackers, I have a plan!  :)
> I've given it enough thinking and belive it'll work
> to mix mark&sweep and reference couning.
> 
> Just, I don't have much time to do, and there's in particular
> one portion of the required work which is error prone and
> pretty annoying.
> 
> The annoying part is taking back use of intrusive_ptr for
> all GcResources. If anyone is interested in doing that part I'll
> go on with the rest.
> 
> The shared GC branch already contains the code for the GC part.
> When running almost any movie it segfaults do to inconsistent use
> of intrusive_ptr<GcResource> in current code (most notably one
> in AsSetPropFlags temporarly storing an as_object into an
> intrusive_ptr).
> 
> When the intrusive_ptr use is consistent we should *only* get
> segfaults due to recycling of unreachable circular ref, which would
> be fixed by implementing an override of the GcResource::cleanResourceLinks
> virtual method in the relevant classes.
> 
> NOTE that implementing the consistent use of intrusive_ptr will still
> allow enabling/disabling GC/RC mix by only touching libbase/smart_ptr.h
> so that we can compare memory use and performances.
> 
> --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
  /\   http://strk.keybit.net/services.html



reply via email to

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