On Thu, Sep 2, 2010 at 9:59 AM, Chris Marrin <cmar...@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 <cmar...@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.

webkit-dev mailing list

Reply via email to