[Webkit-unassigned] [Bug 197344] Web Inspector: "Retained Size" does not make sense

[bugzilla-daemon at webkit.org]

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

--- Comment #4 from Joseph Pecoraro <joepeck at webkit.org> ---
> Thanks for the hints. I use a custom implemented React-similar way of state
> handling for a WebGL application where I found out thanks to the "retained
> size" that there is indeed a chain of last states (current -> last -> last
> -> last ...) caused by closures. Unfortunately I cannot extract a simple
> example right now and there is no public link available yet. 

Understood. Building a long chain is all it takes though. You can increase the value of "N" here to easily get over a Terrabyte (N = 1500 for example) in the current implementation. For now this test matches the A.B.C example I listed above:

<script>
setTimeout(() => {
    console.takeHeapSnapshot("before");

    function largeObject() {
        return {__mem: "x".repeat(1024*1024)};
    }

    window.chain = largeObject();
    let last = window.chain;
    let N = 2;
    for (let i = 0; i < N; ++i) {
        last.X = largeObject();
        last = last.X;
    }

    console.takeHeapSnapshot("after");
});
</script>


> So on the one hand this tool helps to find potential non-obvious memory
> leaks caused for example by closures. However on the other hand since this
> accumulated sum showed in my case 781.92 GB I almost ignored it because I
> thought its just a Safari developer tools bug. 
> 
> From https://webkit.org/blog/6425/memory-debugging-with-web-inspector/ I
> found 
> "The retained size is the size of the object plus the size of all of the
> nodes it dominates (the objects that this particular object solely keeps
> alive). An easy way to think about the retained size is if the object were
> to be deleted right now, the retained size would be the amount of memory
> that would be reclaimed."
> 
> According to this explanation it would mean it really should show a concrete
> amount of memory allocated at the moment. The accumulated sum however at the
> top level in Safari developer tools shows some "virtual" calculation which
> does not represent real memory like you already mentioned too.

Yes. And it is concerning that seeing a large number deter'd you temporarily, so we should address that by putting a better number at the top level.

> The question now is if the top level would only show effective 3 MB from
> your example instead of 6 MB would I have found the memory leak too? I guess
> yes however after a longer runtime (here also I would need to make an
> example with concrete calculation, but I don't know if this is needed). 

No matter what we change the top level category number to, I don't think we'd change what happens when you expand the category. So each object would list its individual retained size (and in a chain you'd continue to see large values but nothing as meaningless sum).

> To summarize at the moment it seems to make no sense to investigate more
> since there seems to be no bugs neither in the safari tools nor in my
> application (after removing the leak). However I would really think about
> changing the measurement to have an effective memory footprint instead of a
> accumulated sum to prevent confusion. I had a very bad feeling about what
> should I trust now? Or I guess at least there should somewhere be an
> explanation how it is calculated. When a developer starts to profile it
> means he does not understand 100% anymore what is going on in his code so he
> has to be sure that at least the profiling tools he understands perfectly
> otherwise he has even more unknowns.

We should just put a better number at the top level. Devin had an idea to use some kind of computed value that is the retained size of that class without double counting. I'm not sure precisely how to count that but if we can manage that it would be a better UI. In the example above you'd end up with roughly `(N+1)MB` at the top level as you'd expect.

-- 
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/20190501/18f97abb/attachment.html>