On Thu, Sep 2, 2010 at 8:51 AM, Chris Marrin <cmarrin@apple.com> 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