[Gnash-dev] GC: static (kept alive) resources

[strk]

[moved to gnash-dev for broader audience]

On Mon, Jun 25, 2007 at 10:25:00AM +0800, zou lunkai wrote:
> On 6/24/07, strk <address@hidden> wrote:

> >Btw, I found the bug was due with use of static intrusive_ptrs which with
> >the GC model don't have the effect of keeping pointers alive.
> >We have these choices:
> >
> >       1) explicitly keep them alive by marking as "reachable" at
> >          every run.
> >
> >       2) add a "protected" or "locked" flag to GcResource so that
> >          if the flag is set the object is never removed
> >
> >       3) don't have these objects managed by the GC at all
> >
> >       4) allow explicit deregistration from the GC
> >
> 
> I did a quick search and found  that "static boost::intrusive_ptr" was
> used in file Date.cpp, for AS related object.

And in all other asobj/*.cpp files ...

> So in your above options, I won't choose option 3, just to keep the
> concept "all AS object are managed by GC" clean.  Whether the object
> will be collected/removed by the GC is another question.
> 
> and option 2 will increase the size of all GC managed objects, so I
> just don't like it. We already have a "_reachable", one flag is
> acceptable to me, but two is too much:)

_reachable is a boolean value. I guess any implementation would use a word
for a boolean, so using an int as a bitfield shouldn't really increase the size.

> I don't know how much option 1 will affect the marking or collecting
> speed. But if it does have countable effect, I then don't like it, I
> need Gnash to be as fast as it could be.

Well, the only problem would be deciding where to mark them from.
A possibility could be registering these statics with the VM 
singleton as "objects to keep alive". In that case the 
VM::markReachableResources
could take care of marking. Still, that would mean marking a prototype and all 
it's interfaces at every run when we know from the start we'll *always* mark 
them
so not really an optimal design.

> Option 4 seems fine to me if it does not have implementation
> difficulty compared to option 1,2 and 3. And I don't bother explicit
> actions with GC as I said, since the AS objects themsef have lots of
> exceptions.

Implementation wise deregistering an object from the GC wouldn't be hard.
The problem would be a performance one. If we want deregistrations to be
fast we'll need to store an iterator in each resource, failing to do so
a deregistration would take a complete scan of registered resources in the
worst case. Also, if we do allow not-registered resources, why not using
explicit registration ?

> you should have more comprehensive understandings about GC, so you
> make the final decision:)

Please help  :)
If you need more info just ask and I'll explain.
Note that the current design is aimed at keeping both RC and GC an option
for a quick backup solution.

--strk;