[webkit-dev] WebKit memory instrumentation

[Zoltan Herczeg]

Hi,

> 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:

Unfortunately this part is removed by the mail server, and from webkit-dev
archives, but as far as I remember (we measured the memory consumption of
webkit several times before), the main memory consumers were
JavaScriptCore (to reduce GC calls) and Resource caches, not rendering.

> 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.

This looks complicated and will likely break.

> 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.

Guys here have a lot of experience with static source code analysis, I can
give their contacts if you interested.

Regards,
Zoltan