[webkit-dev] WebKit memory instrumentation
zherczeg at webkit.org
Mon Jul 23 11:14:16 PDT 2012
> Web Inspector that shows the render process memory broken down into
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
> 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
> 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
> 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.
More information about the webkit-dev