Open https://crisal.io/aemet-visualizer
after the page loads, refresh the page by pressing f5. Repeat this step 2 times.

ER: Nomal memory use
AR: Large memory use. And most of it is in heap-unclassified

It's not clear if the memory is style-system related, right? Actually I'd expect it's not given we do measure the rule tree and styles in the page.

I suspect most of it is XHR / fetch related, I pull a whole lot of data. I'll have to do a DMD build to figure out what's going on I guess.

Bug 1555867 includes measurement for the heap allocations.

Also, do you know if the large memory use is a regression from bug 1493420 or not?

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

Also, do you know if the large memory use is a regression from bug 1493420
or not?

I tried, and the page wont stop loading, because your hashmap fix hadnt landed by then...

Also, just to make sure, you have to scroll the page up and down a few times to get the page to have heap-unclassified. Better to f5 the page 2-3 times and scroll up and down.

(In reply to Mayank Bansal from comment #3)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

Also, do you know if the large memory use is a regression from bug 1493420
or not?

I tried, and the page wont stop loading, because your hashmap fix hadnt landed by then...

Ah yeah, you need to jump to builds before bug 1383650, sorry about that :(

Also, just to make sure, you have to scroll the page up and down a few times to get the page to have heap-unclassified. Better to f5 the page 2-3 times and scroll up and down.

Ah, then it's likely graphics / WebRender memory, I'd think.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

(In reply to Mayank Bansal from comment #3)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

Also, do you know if the large memory use is a regression from bug 1493420
or not?

I tried, and the page wont stop loading, because your hashmap fix hadnt landed by then...

Ah yeah, you need to jump to builds before bug 1383650, sorry about that :(
Ok, I used mozregression to try a shippablebuild from 20-May.

Results: Even after scrolling up and down, the memory didnt increase much (250-300MB). I refreshed the page multiple times, managing to increase memory to 800MB, but that quickly went down to the 250-300 MB mark.
So something sure is fishy between 20-May, and 30-May :)
(In the memory report I have attached, IIRC the memory use was ~1.4GB, with 700MB as heap-unclassified)

Also, just to make sure, you have to scroll the page up and down a few times to get the page to have heap-unclassified. Better to f5 the page 2-3 times and scroll up and down.

Ah, then it's likely graphics / WebRender memory, I'd think.

Since the increase in heap-unclassified is in the webprocess, and not the GPU process, my naive guess is this is not related to gfx/WR.

ni?, so that you can see my comment. Maybe try DMD build?

Since the increase in heap-unclassified is in the webprocess, and not the GPU process, my naive guess is this is not related to gfx/WR.

That's probably fair. Still worth waiting until I land bug 1555867 since that should add measurements for some of the style system unclassified memory.

If it still shows up as unclassified I'd be pretty confident it's not style-system-related, but I'll make sure to run a DMD build on it to see what's going on.

about:memory of nightly from https://hg.mozilla.org/mozilla-central/rev/155a7e2117e575ff6de6caa3dfe5b076cb455ae1

I had to f5 multiple times before I could repro the large memory use, and heap-unclassified.

@emilio : ni? you just so you can take a look at the meory report. I dont think this is a stylo bug.

There's various unreported bits:

• SVG mapped attribute declarations are not reported.
• DisplayListBuilder arena.
• Various paths in SVG elements.

I'll fix the SVG mapped attribute ones in a separate bug.

with the latest nightly : https://hg.mozilla.org/mozilla-central/rev/7a44faddc33d2e5d7435fbff216cc022d0fb5e6e

ni? to check comment 9 when I get a chance.

Huh, do you have any add-on that does something mathml-related? There's about 40 megs of nsMathMLmfracFrame which is wild.

About:memory with a new profile

This was taken with a new profile (so no addons), and I refreshed the page a few times with f5 to increase the memory use. The increased memory use goes down in a while.

Huh, there's something clearly going wrong in our frame tree memory reporting... It definitely shouldn't report mathml stuff... I'll take a look, thanks.

That's bug 1560188, we were accidentally reporting some parts of the display list as layout frames.

calling this fixed.