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

[Maciej Stachowiak]

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

> On Wed, Nov 14, 2012 at 2:48 PM, Geoffrey Garen <ggaren at apple.com> wrote:
> 
> This is magical thinking. RenderArena is no different from FastMalloc.
> 
> It's actually different enough to be interesting:

Thanks for sharing these. I think understanding what is different about RenderArena is key to figuring out the right technical direction to take. I personally think improving the allocator to be harder to exploit is a valuable direction to explore. Though I share Geoff's hope that we can end up with a single general-purpose allocator with our desired properties.

With that in mind, and in the spirit of inquiry, here are some follow-up comments and questions.

> - The bucket granularity is different, which affects exploitation significantly.

What specifically is different about the bucket granularity and how does that affect exploitation?

> - The packing is perfect, which might even lead to better memory usage under some patterns, although, yes, it's true that there are possible pathological conditions as noted by Maciej.

If things currently allocated via malloc end up in multiple different arenas, then that seems likely to increase memory fragmentation.

> - free() is more expensive in fastMalloc because of various indirections to work out if we're freeing a page range or a slab slot.
> - RenderArena has freelist poisoning. I'm not sure if freelist poisoning made it into upstream tcmalloc yet.

This seems like something that can readily be included in non-RenderArena allocators.

> - There are very significant differences (from the attackers, and WebKit consumer's point of view) on page reclaim.

Sorry if this is a dumb question, but what is "page reclaim" in this context and what are the differences?

> 
> 
> (1) RenderArena recycles by object size, just like FastMalloc.
> 
> (2) FastMalloc is a slab allocator, just like RenderArena.
> 
> (3) RenderArena grows by calling FastMalloc.
> 
> Isolating object types from each other -- and specifically isolating objects of arbitrary size and contents like arrays -- is an interesting idea. RenderArena is neither necessary nor sufficient for implementing this feature.
> 
> The only reason RenderArena seems isolated from other object types is social, not technical: we actively discourage using RenderArena, so few object types currently use it.
> 
> > 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
> 
> Having dealt with the specific technical question of RenderArena, I'd like to briefly discuss the meta-level of how the WebKit project works.
> 
> Sam Weinig and I both provided review feedback saying that using RenderArena more was a bad idea (https://bugs.webkit.org/show_bug.cgi?id=101087#c9, https://bugs.webkit.org/show_bug.cgi?id=101087#c18). Nonetheless, you r+ed a patch to move in that direction, and you describe it here as the "current plan" for WebKit.
> 
> I'm a little disappointed that, as individual contributors, Chris Neklar and Chris Evans didn't realize or understand the problems listed above, and didn't tackle them.
> 
> We realize RenderArena tradeoffs and have not tackled them in more detail because https://bugs.webkit.org/show_bug.cgi?id=101087 is not the place to do it. https://bugs.webkit.org/show_bug.cgi?id=101087 is a simple clean-up changeset. Eric started this thread in order to start discussing some of the trade-offs with a DOM slab -- something for which we haven't yet uploaded any patches for anyone to r+ or r- :-)

It does seem like there is a difference in philosophy on whether RenderArena should be used more or less, and the patch sort of expresses an opinion on the matter, though it doesn't actually per se move in one particular direction.

Regards,
Maciej




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121114/19eababc/attachment.html>