gnash-dev
[Top][All Lists]
Advanced

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

Re: [Gnash-dev] GC: status report & call for test


From: strk
Subject: Re: [Gnash-dev] GC: status report & call for test
Date: Thu, 5 Jul 2007 16:41:55 +0200

On Tue, Jul 03, 2007 at 01:09:38PM -0700, John Gilmore wrote:

> I think it should be possible (and recommended) to explicitly free
> anything we know we can explicitly free. 

This would not be a big problem, but we'll need to add an iterator
to each collectible resource, for fast deregistration. The GcResource
destructor might do this. By doing this we'd also allow stack (and auto)
allocations.

> sweep the world to notice that it's garbage later.  And since our code
> base supports both GC and RC, we already have the code to do this; we
> just have to make it not be a no-op when in GC mode.  The locality of

This is more a problem as long as both GC and RC implementations are 
intrusive. If we store intrusive_ptr in a class member, and the 
instance pointed-to is destroied by the GC, a segfault would happen
when the intrusive_ptr destructor is is invoked.
This might be fixed by stop using an intrusive model, or by NOT accessing
the pointer if not found in the GC list of managed pointers.
The latter (qurtying the GC list) might also be inaccurate as a pointer
found in the list might be another object, not the original one.

> performance.  If our current garbage collector doesn't permit this,
> then let's fix our current garbage collector so it does.

We surely can think about this. The current GC is just the first pass.

> Second, the code that creates circular reference structures KNOWS that
> it's creating them, much of the time.  When we disassemble such a
> structure, in reference counting mode, we should disassemble it
> despite the circular references.

It doesn't always know, as the default relation is just a default.
Users (ActionScript coders) can still change this relationship.
a function's "constructor" member is a pointer to self, but
might be changed to point to something else:

        A = function() {}
        B = function() {}
        A.prototype.constructor = B.prototype.constructor;
        delete A;

> (Pointers from the call stack to a function would be ordinary RC
> pointers, which would increment the reference count.  If the function
> is in the call stack and its name is then deleted, the function would
> stay live because the reference count is >0.  Once the call stack
> returned, and decremented the refcount to zero, the function
> (including its circular reference) would be destroyed.)

In the case above, A.prototype.constructor would be destroyed by
last line, while still in use by B, which is alive.

--strk;




reply via email to

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