[webkit-dev] WebKit memory instrumentation

[Zoltan Horvath]

Hi there,

On Mon, 23 Jul 2012 17:09:19 +0200, Yury Semikhatsky <yurys at chromium.org>  
wrote:

> *Hi WebKit,
>
> Almost all developers would like to know why the render process takes so
> much memory. We are trying to address this problem by providing an
> information on how much memory is consumed by some high-level WebKit
> parts(DOM, CSS, JavaScript etc) . Currently there is  a real-time chart  
> in
> Web Inspector that shows the render process memory broken down into  
> several
> components:
>
>
> To achieve that we instrumented several classes in
> WebCore<http://code.google.com/searchframe#search/&q=reportMemoryUsage%20package:chromium&type=cs>to
> report an estimation of their memory footprint. The main problem with
> that approach is that it can be easily broken by changes to the
> instrumented clasess. We need a way to guard from such changes that would
> automatically validate the instrumentation and make sure it matches  
> current
> class structure.

The goals are cool! Have you talked about how much code would be  
introduced/changed by this approach?

> We see several ways of doing that.
>
> First option we consider is to define a class with the same set of fields
> as the instrumented one, then have a compile time assert that size of the
> reference class equals to the size of the instrumented one. See
> https://bugs.webkit.org/attachment.cgi?id=153479&action=review for more
> details.
>
> Pros: compile time error whenever size of an instrumented class changes
> with the appropriate modifications to the instrumentation function.
> Cons: it will require each committer to adjust the reference class and  
> the
> instrumentation on any modification that affects size of the instrumented
> class. Changes that don't affect size of the class will go unnoticed.

I think we can't demand this from the committers. Although it seems a  
trivial task to do the modification, it's too much effort to take care of  
these individually. Can't we just automatize it somehow (or support the  
modifications) with a clever script?

> The second option is to write a tool/script/llvm-plugin and use it on a
> build-bot to monitor the relevance of instrumentation and update it on  
> when
> a new field is added to an already instrumented class. However, a  
> question
> remains who and how often would do this.
> Pros: a committer may not need to update the instrumentation immediately.
> Cons: the instrumentation may be behind the actual memory usage. An
> addifitional effort required to create the tooling.

This sounds a bit better for me, I think the effort that we put on tooling  
will save time later. Since we can tell that when the change and its  
instrumentation were introduced, the delay shouldn't be a big trouble.

> We would like to know what you think about it and will greatly appreciate
> any ideas and suggestions.

Done. :)

> Regards,
> Yury, Alexei, Ilya
> *

Cheers,
<Zoltan>