After giving about 30mins, the browser returned to useable stage. I confirmed that version number is 70.0.3510.0.

Memory use is down to 900M!

We appear to be creating but not destroying a lot of objects in the TINY malloc zone:

"""
26731                                           VIRTUAL   RESIDENT      DIRTY    SWAPPED ALLOCATION      BYTES DIRTY+SWAP          REGION
26732 MALLOC ZONE                                  SIZE       SIZE       SIZE       SIZE      COUNT  ALLOCATED  FRAG SIZE  % FRAG   COUNT
26733 ===========                               =======  =========  =========  =========  =========  =========  =========  ======  ======
26734 DefaultMallocZone_0x10dce4000               31.8G      22.6G      22.4G       9.1G  117159059      21.5G       9.9G     32%   24663
26735 QuartzCore_0x11cf4b000                      48.0M       812K       812K        80K       8795       578K       314K     36%      27
26736 DefaultPurgeableMallocZone_0x115f05000         4K         4K         4K         0K          0         0K         4K    100%       1
26737 GFXMallocZone_0x10dd0b000                      0K         0K         0K         0K          0         0K         0K      0%       0
26738 ===========                               =======  =========  =========  =========  =========  =========  =========  ======  ======
26739 TOTAL                                       31.8G      22.6G      22.4G       9.1G  117167854      21.5G       9.9G     32%   24691
...
26712 MALLOC_TINY                       22.9G    21.6G    21.4G     1.3G       0K       0K       0K    23447         see MALLOC ZONE table below
26713 MALLOC_TINY (empty)               4096K      48K      48K       0K       0K       0K       0K        5 
"""

Fragmentation is 32% which is pretty standard. 

vmstat after going to 900m.

Also memory-infra.

Deleted: vmstat_macviews2.txt 755 KB

vmstat_macviews2.txt 755 KB View Download

Deleted: trace_memory_infra_macviews.json.gz 50.2 KB

trace_memory_infra_macviews.json.gz 50.2 KB Download

Another memory infra dump since the other one wasn't complete.

Deleted: trace_with_heap_dump_macviews2.json.gz 248 KB

trace_with_heap_dump_macviews2.json.gz 248 KB Download

This problem is caused by browser process app-napping while renderers do not thus causing IPCs to queue up. I thought that this CL had fixed this:

https://chromium-review.googlesource.com/c/chromium/src/+/1057458

But clearly not. We need to explicitly disallow.

Deleted: Screen Shot 2018-08-06 at 10.55.00 AM.png 96.6 KB

	Screen Shot 2018-08-06 at 10.55.00 AM.png 96.6 KB View Download

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

commit cb5154c8b03bd393b7226867d8b31a71772f8d15
Author: erikchen <erikchen@chromium.org>
Date: Mon Aug 06 18:22:58 2018

macOS: Disable AppNap for browser process.

Renderers never go to sleep. If the browser goes to sleep, IPC messages will
queue up. When the browser finally wakes up, it can stall for 30min+ processing
those IPC messages. This CL disables AppNap for the browser process, which will
make sure that IPC messages get processed in a timely fashion.

This CL does not set the Info.plist option NSSupportsAppNap to false, as that
has no effect.

To test:
1) Run
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister
-f <path_to_chrome> if changing the Info.plist.
2) Launch Chrome from the finder.
3) Switch to a different virtual desktop [no chrome windows showing].
4) Launch Activity Monitor, switch to "energy" view, make sure Chrome/Chromium
is visible.
5) Launch Safari and make sure it's the active app.
6) Wait 10 minutes

Expected results:
Chrome/Chromium does not enter AppNap.

Previous results:
Chrome/Chromium does enter AppNap.

Bug:  871235 
Change-Id: I9af05e38b7706c9e61a99316a88fd4ea5fada997
Reviewed-on: https://chromium-review.googlesource.com/1163726
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#580925}
[modify] https://crrev.com/cb5154c8b03bd393b7226867d8b31a71772f8d15/services/service_manager/embedder/mac_init.mm

Pls update bug with canary result tomorrow and provide merge justification, how safe it will be. Thank you.

The NextAction date has arrived: 2018-08-07

This is a low-risk change. It prevents Chrome from being unusable after waking from sleep.

Thank you  erikchen@. Did you get chance to test/verify the bug on latest canary version 70.0.3515.0?

I've confirmed that Canary no longer enters AppNap, which I strongly suspect is responsible for the problem we've seen.

Approving merge to M69 branch 3497 based on comment #11 and #13. Please merge now. Thank you.

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

commit 0e68678d33faf6b8b1c3a856da4664ab347c61c9
Author: erikchen <erikchen@chromium.org>
Date: Tue Aug 07 17:59:47 2018

[Merge to 3497] macOS: Disable AppNap for browser process.

Renderers never go to sleep. If the browser goes to sleep, IPC messages will
queue up. When the browser finally wakes up, it can stall for 30min+ processing
those IPC messages. This CL disables AppNap for the browser process, which will
make sure that IPC messages get processed in a timely fashion.

This CL does not set the Info.plist option NSSupportsAppNap to false, as that
has no effect.

To test:
1) Run
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister
-f <path_to_chrome> if changing the Info.plist.
2) Launch Chrome from the finder.
3) Switch to a different virtual desktop [no chrome windows showing].
4) Launch Activity Monitor, switch to "energy" view, make sure Chrome/Chromium
is visible.
5) Launch Safari and make sure it's the active app.
6) Wait 10 minutes

Expected results:
Chrome/Chromium does not enter AppNap.

Previous results:
Chrome/Chromium does enter AppNap.

Bug:  871235 
Change-Id: I9af05e38b7706c9e61a99316a88fd4ea5fada997
Reviewed-on: https://chromium-review.googlesource.com/1163726
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#580925}(cherry picked from commit cb5154c8b03bd393b7226867d8b31a71772f8d15)
Reviewed-on: https://chromium-review.googlesource.com/1165603
Reviewed-by: Erik Chen <erikchen@chromium.org>
Cr-Commit-Position: refs/branch-heads/3497@{#468}
Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753}
[modify] https://crrev.com/0e68678d33faf6b8b1c3a856da4664ab347c61c9/services/service_manager/embedder/mac_init.mm

Issue 875603 has been merged into this issue.