[webkit-dev] Arena is crufty?

[Darin Fisher]

On Thu, Sep 2, 2010 at 8:51 AM, Chris Marrin <cmarrin at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100902/1a2b6888/attachment.html>