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

commit 0cd83681ad239907cf6fc7c07cfcca1262474529
Author: keishi <keishi@chromium.org>
Date: Mon May 08 11:12:59 2017

Report TeeHelper::Chunk buffer size to V8

Reporting the buffer size of TeeHelper::Chunk to V8 should trigger V8 GC earlier and will hopefully slightly reduce memory usage.

BUG=715928

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

[modify] https://crrev.com/0cd83681ad239907cf6fc7c07cfcca1262474529/third_party/WebKit/Source/modules/fetch/BytesConsumer.cpp

Any updates? What's the latest?

In the linked code review https://codereview.chromium.org/2847543003, there's a comment "But trace taken while telemetry script reloads Flipkart 20 times, clearly shows ~2MB reduction in peak Chunk buffer size"

So keishi@'s patch has taught V8 GC about the buffers used by service worker, and reduced memory.

keishi@ do you have more work planned or recommended for reducing service worker memory usage?

I've been investigating the system_health.memory_mobile/browse.shhopping.flipkart benchmark but my conclusion is that I don't think we can reduce anything for this benchmark.

Overall results look like this:
https://keishi.users.x20web.corp.google.com/www/nosw-results/results.html?r=master&s=%CE%94avg&a=&g=name&c=0&d=&n=0

When I disable service worker i get overall 6MB reduction.

Out of that 6MB almost half is V8 (2.9MB). The V8 team has looked into this and told me they could maybe at best shave a few hundred KB off.

Second largest is BlinkGC (1.4MB). But if you look at blink_gc:allocated_objects_size, it is actually +416.8KB, which means all of the 1.4MB comes from free space. i.e. when we enable service worker we have more memory fragmentation. I looked at the top allocations for both builds and confirmed that they were identical. So I am guessing the difference in fragmentation must come from difference in allocation placements induced by resource load timings. Anyway fragmentation is a hard problem to analyze so I don't think we can do anything at the moment.

Should we do an audit in WebKit to see whether we miss AdjustAmountOfExternalAllocatedMemory() in other places?

(Bumping up the priority given that we'll need serious look anyways)

We discussed how AdjustAmountOfExternalAllocatedMemory() should be used with V8 in the past and the conclusion was that we should use is sparingly only for select objects as it may be a double edged sword.

I hear +hpayer is planning unified V8/Blink GC scheduling, so that API will probably be subject to change in the near future.

Any updates to the status of any investigations? When's a good time to check back?

I think keishi@'s conclusion is above and there is not an active investigation now by the memory or worker team. This is P1 but at least the worker team is overloaded with other P1s (servicification, other performance optimizations).

The worker team basically has an OKR this quarter: "publish a doc about what we know about service worker memory usage, and why we can't reduce it easily", but I don't expect anything groundbreaking. keishi@'s conclusion from investigation and discussion with V8 team in #6 and #9 is that there is no low-hanging fruit and any reduction requires huge changes to V8. I just aim to produce a doc that documents why we think that. So EOQ is a good time to check back.

Deprioritizing to reflect reality. We don't have a plan to work on this in Q4 as mentioned in comment 11.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot