[webkit-dev] Arena is crufty?

[Kenneth Russell]

On Wed, Sep 1, 2010 at 4:36 PM, James Robinson <jamesr at google.com> wrote:
> On Wed, Sep 1, 2010 at 4:20 PM, Chris Marrin <cmarrin at apple.com> wrote:
>>
>> Ken's PODRedBlackTree patch has made me go back and take a closer look at
>> WebKit's Arena "class". Turns out it's not a class at all, just some structs
>> and macros. That seems very un-WebKit-like to me. Ken's patch also has a
>> PODArena class, which uses Arena in its implementation. Sam suggests that
>> PODRedBlackTree should really go into WTF, which means PODArena and Arena
>> would need to go there as well.
>>
>> It seems like Arena really needs to be brought into the 21st century and
>> made a proper class. Maybe now is the right time to:
>>
>> 1) Make Arena a class
>>
>> 2) Integrate Ken's PODArena functionality into this new Arena class (or
>> maybe just make Ken's PODArena the new Arena class).
>>
>> 3) Move the new Arena class to WTF
>>
>> 4) Put PODRedBlackTree in WTF
>>
>> It looks like RenderArena is currently the only client of Arena.h, so this
>> change shouldn't be too hard. Of course, looking at RenderArena, it's a
>> little odd, too. It is not renderer specific at all. It's just an Arena that
>> recycles freed objects. Maybe we should move that functionality into the new
>> Arena class. But RenderArena is used all over the place, so maybe that's
>> going one step too far down this road?
>
> I'm pretty sure we want to delete RenderArena (since
> the minuscule-to-negative performance gain is not worth the extra
> complexity) at some point anyway.  If that is still the case, then maybe it
> makes more sense to have PODArena be the only arena class in WebKit.
> I'm not sure we have to move PODArena / PODRedBlackTree to WTF right away,
> but it can't hurt.  My gut feeling is that historically most classes that
> think they want Arenas actually do not need the extra complexity and we
> shouldn't encourage more users of arena classes without some discussion.  I
> actually prefer having PODArena be an implementation detail of
> PODRedBlackTree and not exposed as a general utility until we have a clear
> need for something else to use it.

There is more code coming, outside of the red/black tree, which uses
PODArena to allocate (lots) of small temporary objects and then throw
them all away at the end. I definitely do not want to have to add
bookkeeping for these temporary objects, which would be required if
the PODArena weren't available.

PODArena is not designed to be a replacement for the ArenaPool
functionality; it's just a consumer. I'd rather start to land the code
in this place before doing major restructurings.

-Ken

> - James
>
>>
>> -----
>> ~Chris
>> cmarrin at apple.com
>>
>>
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>