[webkit-dev] RenderArena: Teaching an old dog new tricks

[Ryosuke Niwa]

On Wed, Nov 14, 2012 at 3:19 PM, Chris Evans <cevans at chromium.org> wrote:

> On Tue, Nov 13, 2012 at 11:14 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>
>> On Tue, Nov 13, 2012 at 10:23 PM, Eric Seidel <eric at webkit.org> 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/webkit-dev@lists.webkit.org/msg12681.html
>>>
>>> The (unfortunate?) reality is that we've failed to do so, despite
>>> trying several times.
>>> http://www.mail-archive.com/webkit-dev@lists.webkit.org/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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121114/d9df35eb/attachment.html>