On Wed, Nov 14, 2012 at 3:19 PM, Chris Evans <[email protected]> wrote:
> On Tue, Nov 13, 2012 at 11:14 PM, Ryosuke Niwa <[email protected]> wrote: > >> On Tue, Nov 13, 2012 at 10:23 PM, Eric Seidel <[email protected]> wrote: >> >>> RenderArena was a perf optimization for the rendering tree, which >>> hyatt imported from Mozilla 10 years ago: >>> http://trac.webkit.org/changeset/2635 >>> >>> The prevailing lore has long been that RenderArena is no longer >>> useful, ugly, and should be killed! >>> http://www.mail-archive.com/[email protected]/msg12681.html >>> >>> The (unfortunate?) reality is that we've failed to do so, despite >>> trying several times. >>> http://www.mail-archive.com/[email protected]/msg12682.html >> >> >> I don't think we have failed. The messages posted on the thread don't >> indicate anyone has tried to delete the render arena recently. I support >> any attempts to remove it. >> > > A first step might be to make it a platform define. For the Chromium > platform we'd leave the define "on" -- there are some nice security > properties we get from having the RenderObjects in their own spot. I'm > happy to go in to more details if you want, but it's similar (although not > identical) to the blog post linked by Brendan regarding Firefox. > If we like the properties of RenderArena, then why don’t we modify FastMalloc to have the same property, possibly behind a build flag? We can then make all render objects to be ref-counted and get rid of RenderArena. That’ll give us two layers of defense (for all objects; DOM, CSS, etc...) by making it 1. hard to free prematurely and 2. hard to override vtable pointers. Having two independent ways of allocating an arbitrary object imposes a significant maintenance burden on the project much like having multiple build systems. - R. Niwa
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
