On Wed, Sep 1, 2010 at 4:36 PM, James Robinson <jam...@google.com> wrote: > On Wed, Sep 1, 2010 at 4:20 PM, Chris Marrin <cmar...@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 >> cmar...@apple.com >> >> >> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev