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: John Gilmore
Subject: Re: [Gnash-dev] GC: status report & call for test
Date: Tue, 03 Jul 2007 13:09:38 -0700

> Correct me if I'm wrong, but any function *call* causes registration
> of at least 2 GC resources (reference to self in the call stack). So,
> 5 calls to functions in one frame will cause the GC to run at frame
> time. At the other hand, these *are* resources that can only be freed
> by the GC (circular reference)...

I'm a bit confused.  

I think it should be possible (and recommended) to explicitly free
anything we know we can explicitly free.  It's much cheaper to do this
at a point in the code when we know it's garbage, than to mark and
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
reference will also be improved when the memory is immediately re-used
for the next allocation, which will improve processor cache
performance, memory fragmentation and total usage, and paging
performance.  If our current garbage collector doesn't permit this,
then let's fix our current garbage collector so it does.

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.

For example, the RC support could have a way to create a "circular
reference pointer", defined as: whenever the pointed-to object is
freed, the circular reference pointer is ALWAYS also freed.  Such a
pointer would not increment the reference count on the pointed-to
object when the pointer is created; and would not decrement the
reference count when the pointer is destroyed.  Using these in
situations where we know we're creating circular references WOULD
allow RC to properly destroy deleted functions.

(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.)

        John








reply via email to

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