On Thu, Sep 2, 2010 at 8:51 AM, Chris Marrin <[email protected]> wrote:
> > On Sep 1, 2010, at 7:20 PM, Kenneth Russell wrote: > > > I would be happy to not add another Arena client, but the primary > > reason I need an arena is not just for performance but to avoid having > > to keep track of all of the objects I need to delete. > > > > Is there any consensus yet on how to proceed with > > https://bugs.webkit.org/show_bug.cgi?id=45059 ? I'm concerned about > > taking on large-scale restructuring with potential performance impact > > as a prerequisite for my landing any initial code. I could revert my > > PODArena class to use its own memory allocation rather than that in > > Arena.h. > > I just posted that it seems like your RB tree could be replaced by > std::multimap. And, given comments from others, it seems like the right > thing to do with Arena is to put PODArena into the gpu directory like you > were originally going to do, but to not use Arena.h (suck it's functionality > into PODArena). Alternately, you could try Jeremy's idea and ref count your > objects. If you use std::multimap, elements can be of type > RefPtr<something>, so you can avoid all memory management issues. > > I thought there was a policy against using STL container classes in WebKit. Am I imagining things? Aren't there concerns about how STL container classes handle OOM situations, throwing exceptions, and so on? If the conclusion is for PODArena to live in graphics/gpu/ as originally proposed (without a dependency on Arena.h as originally written), and if using STL container classes is indeed verboten, then I'd like to propose that PODRedBlackTree also have its home be in graphics/gpu/. If there comes a time that we want to use these classes elsewhere in WebKit, then we can move them to a more general location, but at least they will be built as generic classes from the start. I can't tell who needs to agree to this before we can move forward. Any objections? Regards, -Darin
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
