[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 <[EMAIL PROTECTED]> 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; _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
