User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0 Build ID: 20180928220433 Steps to reproduce: Enable WR 1.I used my regular profile for about 1 hour, mostly bugzilla pages, and profiler pages 2. Closed all tabs, and checked memory use is task manager. IT showed 800MB in one process 3. I opened about:memory, minimized the memory, and saved a report Actual results: GPU (pid 8988) Explicit Allocations 701,607,936 B (100.0%) -- explicit ├──668,156,016 B (95.23%) ── heap-unclassified ├───15,560,000 B (02.22%) -- threads Expected results: not so, specially after closing all tabs, and minimizing memory manually

Hm, that seems bad. Given that it's unclassified, memory reporters aren't going to help here. If you're willing to help debug further, I think there are basically two approaches: (1) Narrow down a reduced STR, or (2) Run your session with instrumentation. If you can reduce it down to a small set of pages and/or actions, that's obviously ideal. I think the best approach for option (2) would be to use WPT, via the instructions at [1], and send me a trace. [1] https://wiki.mozilla.org/Tracing_VirtualAlloc_With_Xperf

I was able to repro this under WPT. But the resultant file was 13GB uncompressed, and 1GB+ compressed. There is no way I can upload that much data I opened a ton of bugzilla tabs, 1 gmail, a couple of github tabs. And I scrolled a lot on the bugzilla pages. Is that information useful in adding some logging or something?

with image.mem.debug-reporting enabled

Might this be related to bug 1495661?

I dont see such large heap-unclassified now. In fact, memory use is much better now. I wouldnt mind calling this bug as FIXED, specially as I dont have exact STR

Sounds good. Thanks for retesting!