[webkit-dev] Arena is crufty?

[Kenneth Russell]

On Thu, Sep 2, 2010 at 9:59 AM, Chris Marrin <cmarrin at apple.com> wrote:
>
> On Sep 2, 2010, at 9:41 AM, Kenneth Russell wrote:
>
>> 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 haven't seen that reply yet, but replacing my red-black tree with
>> std::multimap is not a solution. My red-black tree is specifically
>> designed to be augmentable, and the IntervalTree built on it is a core
>> data structure used in the path processing code.
>
> The wheels go round and round.
>
> Seems like the right solution is to put PODRedBlackTree and PODArena in gpu as originally planned. But still suck in the functionality of Arena.h rather than using it directly. That gives us the option of getting rid of Arena.h at some point.

Done. New patch coming soon. No take backs.

-Ken