[Webkit-unassigned] [Bug 141247] New: [REGRESSION][Bmalloc] Implement reporting of malloc statistics.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=141247

            Bug ID: 141247
           Summary: [REGRESSION][Bmalloc] Implement reporting of malloc
                    statistics.
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P1
         Component: WebCore Misc.
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: clopez at igalia.com
                CC: cgarcia at igalia.com, dbates at webkit.org,
                    ggaren at apple.com, gyuyoung.kim at webkit.org,
                    mitica at adobe.com, ossy at webkit.org, rniwa at webkit.org,
                    zan at falconsigh.net, zoltan at webkit.org

Our performance tests, use the JS call window.internals.mallocStatistics() to get information about the internal malloc stats on WebKit.

This information is collected by the tool running the performance tests and displayed on the graphs of http://perf.webkit.org

This feature was added on r123773 <http://trac.webkit.org/r123773> (Check bug 78984)

On bug 139812 I wondered why the Mac performance bots don't report any information about the malloc stats.

It turns out the cause is that bmalloc still don't implements this.
I just tested bmalloc on Linux (bug 140162) and I also get 0 bytes reported on the malloc stats of any performance test.

For example, on the link below you can see how the mac bot stopped reporting any information about malloc stats once bmalloc was made the default allocator.
Linux bots (GTK/EFL) still report this information because they are still using TCMalloc.
https://perf.webkit.org/#mode=charts&chartList=%5B%5B%22efl%22%2C%22Parser%2Fhtml5-full-render%3AMalloc%22%5D%2C%5B%22gtk%22%2C%22Parser%2Fhtml5-full-render%3AMalloc%22%5D%2C%5B%22mac-mavericks%22%2C%22Parser%2Fhtml5-full-render%3AMalloc%22%5D%2C%5B%22mac-yosemite%22%2C%22Parser%2Fhtml5-full-render%3AMalloc%22%5D%5D&days=351

I think this is a regression, since now we lack of proper information about the memory usage/consumption and we can't identify revisions that cause huge increases on the memory usage. 

The (stub) implementation for bmalloc seems to be there: http://trac.webkit.org/browser/trunk/Source/WTF/wtf/FastMalloc.cpp?rev=179600#L339
The one for tcmalloc that was working previously: http://trac.webkit.org/browser/trunk/Source/WTF/wtf/FastMalloc.cpp?rev=179600#L4552

I'm not planning to implement this, so feel free to take it if you want.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150204/cc630d31/attachment-0002.html>