<br><br><div class="gmail_quote">On Mon, Jul 23, 2012 at 8:07 PM, Zoltan Horvath <span dir="ltr"><<a href="mailto:zoltan@webkit.org" target="_blank">zoltan@webkit.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hi there,<br>
<br>
On Mon, 23 Jul 2012 17:09:19 +0200, Yury Semikhatsky <<a href="mailto:yurys@chromium.org" target="_blank">yurys@chromium.org</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
*Hi WebKit,<div class="im"><br>
<br>
Almost all developers would like to know why the render process takes so<br>
much memory. We are trying to address this problem by providing an<br>
information on how much memory is consumed by some high-level WebKit<br>
parts(DOM, CSS, JavaScript etc) . Currently there is a real-time chart in<br>
Web Inspector that shows the render process memory broken down into several<br>
components:<br>
<br>
<br></div><div class="im">
To achieve that we instrumented several classes in<br></div>
WebCore<<a href="http://code.google.com/searchframe#search/&q=reportMemoryUsage%20package:chromium&type=cs" target="_blank">http://code.google.<u></u>com/searchframe#search/&q=<u></u>reportMemoryUsage%20package:<u></u>chromium&type=cs</a>>to<div class="im">
<br>
report an estimation of their memory footprint. The main problem with<br>
that approach is that it can be easily broken by changes to the<br>
instrumented clasess. We need a way to guard from such changes that would<br>
automatically validate the instrumentation and make sure it matches current<br>
class structure.<br>
</div></blockquote>
<br>
The goals are cool! Have you talked about how much code would be introduced/changed by this approach?<div class="im"><br></div></blockquote><div>We need to add one method for each "interesting" class that would report its structure. So far we've instrumented about 20 classes and got a pretty good coverage (unknown part is ~10-40% depending on the site).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We see several ways of doing that.<br>
<br>
First option we consider is to define a class with the same set of fields<br>
as the instrumented one, then have a compile time assert that size of the<br>
reference class equals to the size of the instrumented one. See<br>
<a href="https://bugs.webkit.org/attachment.cgi?id=153479&action=review" target="_blank">https://bugs.webkit.org/<u></u>attachment.cgi?id=153479&<u></u>action=review</a> for more<br>
details.<br>
<br>
Pros: compile time error whenever size of an instrumented class changes<br>
with the appropriate modifications to the instrumentation function.<br>
Cons: it will require each committer to adjust the reference class and the<br>
instrumentation on any modification that affects size of the instrumented<br>
class. Changes that don't affect size of the class will go unnoticed.<br>
</blockquote>
<br></div>
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?<div class="im">
<br></div></blockquote><div>We considered putting the code collecting memory data separately from the instrumented classes and generating it but given that we needed to access private fields we preferred current approach. The tool described as the second option could generate a possible fix for the instrumentation if there is an error. That code can be manually committed then.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The second option is to write a tool/script/llvm-plugin and use it on a<br>
build-bot to monitor the relevance of instrumentation and update it on when<br>
a new field is added to an already instrumented class. However, a question<br>
remains who and how often would do this.<br>
Pros: a committer may not need to update the instrumentation immediately.<br>
Cons: the instrumentation may be behind the actual memory usage. An<br>
addifitional effort required to create the tooling.<br>
</blockquote>
<br></div>
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.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We would like to know what you think about it and will greatly appreciate<br>
any ideas and suggestions.<br>
</blockquote>
<br></div>
Done. :)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Regards,<br>
Yury, Alexei, Ilya<br>
*<br>
</blockquote>
<br>
Cheers,<br>
<Zoltan><div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">http://lists.webkit.org/<u></u>mailman/listinfo/webkit-dev</a><br>
</div></div></blockquote></div><br>