[webkit-dev] WebKit memory instrumentation

[Andreas Kling]

Hi guys,

First off, this is a really neat addition for web and WebKit developers
alike, so thanks for hacking it!

We're already using the "reference class with same size as original class"
pattern to guard against object size regression for some of our very
high-volume objects. While that's fine for those  issues, I worry that it
won't be sufficient in your case since a refactoring could easily replace
one member with another, changing the effective memory consumption with no
change to sizeof(Object).

I know from experience that anything in this area that isn't tested at
compile-time *will* break/bloat eventually.

-Kling

On Mon, Jul 23, 2012 at 4:09 PM, 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.
>
> 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.
>
> 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.
>
> We would like to know what you think about it and will greatly appreciate
> any ideas and suggestions.
>
> Regards,
> Yury, Alexei, Ilya
> *
> _______________________________________________
> 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/20120723/3d4742b6/attachment.html>