Attaching screenshot. Lots of traces at: https://x20web.corp.google.com/~perezju/memory_infra/cr619929/

Result summary:
https://x20web.corp.google.com/~perezju/memory_infra/cr619929/results.html

Deleted: malloc_goes_down.png 31.2 KB

	malloc_goes_down.png 31.2 KB View Download

It seems that if we wait long enough we might be able to achieve the holy grail of modern computing: negative memory usage!

Screenshot is for: system_health.memory_mobile:load_tools-memory:webview:all_processes:reported_by_chrome:malloc:effective_size_avg where the effect is more dramatic, bot other sets show similar trends.

This smells to me to be the overhead estimation from tracing being wrong and too aggressive. Or maybe something odd in the TBMv2 metric plumbing.
I think the good datapoints here would be:
 - Does the same happen with chrome or is specific to WebView?
 - Does it happen if you repeat only one page over and over?

Re: "Does it happen if you repeat only one page over and over?"

No. I did try repeating a single page 50 times, and did not reproduce the behavior.

I'll try running again on Chrome and see if that makes a difference.

Ok there are two orthogonal problems which have a combined funky side effect here:

1) Both memory reported by malloc and skia sk_resource_cache seems to increase over time in WebView. I know that this is NOT what the picture above shows (I'll get to this below) but this is the data I see in opening the traces in #1, for instance if you open side-by-side [1] and [2]
tobiasjs@ can you help triaging this bug form this side? THe patter seems to be that the more pages we visit, the more bitmap-shared objects we get in skia/sk_resource_cache in WebView.

2) It seems that the memory skia reports in memory-infra in [3] is over-estimating the size of bitmap-shader objects. What's happening here is that the effective-size of malloc is: (total reported by mallinfo()) - (total reported by suballocations like skia).
If you look at both terms, both are growing over time. The problem is that skia totals are growing faster than malloc, causing the funny negative trend.
ssid@ did you wrote the skia dumper code? Can you help triaging this part?

[1] http://www/~perezju/memory_infra/cr619929/load_media_9gag45.html
[2] http://www/~perezju/memory_infra/cr619929/load_media_9gag79.html
[3] https://cs.chromium.org/chromium/src/third_party/skia/src/core/SkResourceCache.cpp?rcl=0&l=681

I tried to investigate why the size calculations are wrong.
The size calculated by SkPictureShader::refBitmapShader almost matches the size allocated by SkMallocPixelRef::NewUsing. The assert says the the reported size is always less than size allocated (if allocated).
So, the only reason i can think of is that the cache holds records of memory which have not been allocated yet or have already been deleted. From the code it looks like the cache will own the memory allocated and memory is freed when records are deleted. So, there can be no stale bitmap-shader entries.

So, the only reason I can think of is that the resource cache reports memory that has not actually been allocated.
From a few heap profile traces I could find that SkCanvas::onDrawRect creates the records in cache while SkCanvas::restore or SkCanvas::internalDrawDevice allocates the memory, but the calls from SkRecordDraw are hard to follow because of multiple visitors, and also I am not sure if this is the only case that triggers allocations.

+fmalita Is it possible that resource cache reports memory that is not allocated, specially in case of bitmap-shader?

There are also few cases where the number reported by resource cache is less than the memory actually allocated by SkMallocPixelRef::NewZeroed.

Attached a trace where SkMallocPixelRef::NewZeroed - 5.2 MB,
while sk_resource_cache from malloc - 1.3 MB.

Deleted: trace_bitmap_shader.json.gz 2.2 MB

trace_bitmap_shader.json.gz 2.2 MB Download

Skia reports bitmap-sharers for which the actual memory allocation (malloced) does not exist.

The bitmap shader is backed by an image generator and the image generator can clear the pixels generated. But it always reports memory used without considering if the bitmap is alive.
BitmapShaderRec::bytesUsed should depend on memory allocated by image generator.

Can someone from Skia team tell me how to fix this?

The following revision refers to this bug:
  https://skia.googlesource.com/skia.git/+/c9a9ca934b936512a486674cfe06fd1c132b4723

commit c9a9ca934b936512a486674cfe06fd1c132b4723
Author: fmalita <fmalita@chromium.org>
Date: Wed Oct 12 20:43:43 2016

Fix double-accounting of SkPictureShader bitmap memory

The pixels RAM is accounted via SkImageGenerator/SkImageCacherator, we
don't need to report it as part of SkPictureShader's BitmapShaderRec.

R=reed@google.com
BUG= chromium:619929 
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2415673002

Review-Url: https://codereview.chromium.org/2415673002

[modify] https://crrev.com/c9a9ca934b936512a486674cfe06fd1c132b4723/src/core/SkPictureShader.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9d82356b6496bb090bd743be75774a9c4b9918e3

commit 9d82356b6496bb090bd743be75774a9c4b9918e3
Author: skia-deps-roller <skia-deps-roller@chromium.org>
Date: Wed Oct 12 22:53:10 2016

Roll src/third_party/skia/ 71c5393b7..cc300a15d (3 commits).

https://chromium.googlesource.com/skia.git/+log/71c5393b73d1..cc300a15d49f

$ git log 71c5393b7..cc300a15d --date=short --no-merges --format='%ad %ae %s'
2016-10-12 mtklein GN/Win: flesh out compiler flags.
2016-10-12 fmalita Fix double-accounting of SkPictureShader bitmap memory
2016-10-12 mtklein GN/Win: support win_toolchain asset?

BUG= 619929 

CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
TBR=jvanverth@google.com

Review-Url: https://codereview.chromium.org/2405273004
Cr-Commit-Position: refs/heads/master@{#424894}

[modify] https://crrev.com/9d82356b6496bb090bd743be75774a9c4b9918e3/DEPS

Going through some old bugs, is there any work left to do here?

I believe it's fixed, but I haven't been able to repro the issue.  If you get a chance, can you confirm/verify?