[webkit-dev] RenderArena: Teaching an old dog new tricks
Chris Evans
cevans at chromium.org
Wed Nov 14 15:19:21 PST 2012
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.
Not all WebKit consumers need weight things the same way as the Chromium
port of course, but at least for us, the security win outweighs any quirks
of RenderArena.
>
> Since RenderArena is generic, the current plan to move it to WTF (as
>> by Chris Marrin suggested back in
>> http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg12672.html),
>> clean up the code further, and investigate wider deployment (like to
>> the DOM tree) for the security benefit and possible perf win.
>> https://bugs.webkit.org/show_bug.cgi?id=101087
>
>
> How does this work when a node is adopted from one document to another?
> DOM arena (or whatever we call it) will not be tied to a document?
>
That's a possible implementation, and a simple one. I like simple, but it
does lead into questions along the lines of those asked by Maciej: are
there significant pathological conditions present that would not be present
with the original allocator? Do these conditions outweight the benefits?
etc.
Cheers
Chris
>
> - R. Niwa
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121114/0fdb8b9c/attachment.html>
More information about the webkit-dev
mailing list