New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 683345 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Feature
Hotlist-MemoryInfra



Sign in to add a comment

Developer Tools heap snapshot feature is very memory-hungry, and should save the snapshot before trying to load it

Project Member Reported by w...@chromium.org, Jan 20 2017

Issue description

Chrome Version: 57.0.2970.0 (Official Build) dev (64-bit)
OS: ChromeOS

What steps will reproduce the problem?
(1) Find a page or extension with a large heap (in my case an extension w/ a 375MB JS heap)
(2) Open Developer Tools and choose Memory.
(3) Take a heap snapshot.

What is the expected result?

(1) Expect that taking a snapshot increases memory usage, but no more than, say, 2x.
(2) Expect that the snapshot is, or at least can be, saved to persistent storage before being visualized.

What happens instead?

(1) Taking a heap snapshot caused the extension renderer process to balloon to ~1.6GB in size (i.e. an increase of about 4-5x), placing it close to the 2GB renderer memory limit. To try to debug the high memory condition almost OOM'd the renderer :P

(2) Once the snapshot was captured, Developer Tools decided to load it. This consumed ~1.2GB at peak (3-4x the extension's original memory footprint). This was in addition to the extension itself still holding 1.6GB of RAM, so an overall overhead of about 7x the memory footprint of the extension.

(3) Even after the snapshot had completed loading, and the extension's memory usage dropped down again, it stayed at around 750MB (about double the original usage) until Developer Tools was stopped.
 

Comment 1 by w...@chromium.org, Jan 20 2017

Cc: primiano@chromium.org nasko@chromium.org
Labels: -Type-Bug Type-Feature
Status: WontFix (was: Untriaged)
I just took a snapshot of my gmail (JS head = 325MB) and my DevTools is now taking 640MB. The heap snapshot processing worker is taking 551MB, which is less that 2x the raw heap, that's fine.

After closing DevTools, it leaks ~10%, which is likely to be due to object unique ids stored in the v8 objects.

Overall, we consider heap profiler being reasonable as long as it handles gmail-size heap within 30 seconds and renderer memory limits.

Sign in to add a comment