1435016 - Inactive tabs of image resources occupy memory as if they weren't inactive

Status: REOPENED

(Core :: Graphics: ImageLib, defect, P3)

Description

[Richard Newman [:rnewman]]

Poking around about:memory after a restart:

├───25,808,128 B (03.26%) -- images
│   ├──12,585,888 B (01.59%) -- content
│   │  ├──11,116,528 B (01.40%) -- raster
│   │  │  ├──10,435,248 B (01.32%) -- used
│   │  │  │  ├───5,329,360 B (00.67%) ++ image(1280x930, http://www.hunt101.com/data/500/JK1.jpg)
│   │  │  │  ├───3,060,176 B (00.39%) -- image(1024x682, http://farm9.staticflickr.com/8311/8031093975_29641e1cae_b.jpg)


Those tabs are zombies, but the image is in memory. As you can see, those two images alone are 8MB; after a relaunch on my current tab set we're about 25MB larger than we should be.

Comment 1

[Richard Newman [:rnewman]]

Actually, this seems to be due to Tab Center — where every other tab's favicon is loaded, Tab Center ends up loading the image itself.

Comment 2

[Richard Newman [:rnewman]]

Reproduced without Tab Center:

│   │  │  │  ├─────561,456 B (00.07%) -- image(290x444, http://static.flickr.com/97/228965306_537bb5b368_o.jpg)
│   │  │  │  │     ├──516,256 B (00.06%) -- locked/cannot_substitute/surface(290x444)
│   │  │  │  │     │  ├──516,096 B (00.06%) ── decoded-nonheap
│   │  │  │  │     │  └──────160 B (00.00%) ── decoded-heap

Comment 3

[Timothy Nikkel (:tnikkel)]

Generally we don't throw away the decoded image immediately, instead we let it expire. So what are the steps you are using here to reproduce?

Comment 4

[Worcester12345]

Horribly slow here, consuming great amounts of memory. Is there something from about:memory I can copy/paste here to help you in any way? 

I was able to find this:

36.45 MB (100.0%) -- images
├──26.88 MB (73.74%) -- content
│  ├──21.07 MB (57.81%) -- raster
│  │  ├──21.00 MB (57.62%) -- used
│  │  │  ├──13.78 MB (37.81%) ── decoded-heap
│  │  │  └───7.22 MB (19.81%) ── source
│  │  └───0.07 MB (00.19%) ++ unused
│  └───5.81 MB (15.93%) -- vector/used
│      ├──5.80 MB (15.92%) ── source
│      └──0.00 MB (00.01%) ── decoded-heap
├───5.25 MB (14.41%) -- chrome
│   ├──4.99 MB (13.69%) -- vector/used
│   │  ├──4.98 MB (13.67%) ── source
│   │  └──0.01 MB (00.02%) ── decoded-heap
│   └──0.26 MB (00.72%) ++ raster/used
└───4.32 MB (11.85%) -- uncached
    ├──2.25 MB (06.16%) -- vector/used
    │  ├──2.24 MB (06.15%) ── source
    │  └──0.00 MB (00.01%) ── decoded-heap
    └──2.07 MB (05.69%) -- raster
       ├──2.06 MB (05.65%) -- used
       │  ├──1.79 MB (04.91%) ── source
       │  └──0.27 MB (00.73%) ── decoded-heap
       └──0.02 MB (00.04%) ── unused/source


Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 ID:20171024165158

I am also running (I think) version 59 on another PC/profile.

Comment 5

[Timothy Nikkel (:tnikkel)]

(In reply to Worcester12345 from comment #4)
> Horribly slow here, consuming great amounts of memory. Is there something
> from about:memory I can copy/paste here to help you in any way? 
> 
> I was able to find this:
> 
> 36.45 MB (100.0%) -- images
> ├──26.88 MB (73.74%) -- content
> │  ├──21.07 MB (57.81%) -- raster
> │  │  ├──21.00 MB (57.62%) -- used
> │  │  │  ├──13.78 MB (37.81%) ── decoded-heap
> │  │  │  └───7.22 MB (19.81%) ── source
> │  │  └───0.07 MB (00.19%) ++ unused
> │  └───5.81 MB (15.93%) -- vector/used
> │      ├──5.80 MB (15.92%) ── source
> │      └──0.00 MB (00.01%) ── decoded-heap
> ├───5.25 MB (14.41%) -- chrome
> │   ├──4.99 MB (13.69%) -- vector/used
> │   │  ├──4.98 MB (13.67%) ── source
> │   │  └──0.01 MB (00.02%) ── decoded-heap
> │   └──0.26 MB (00.72%) ++ raster/used
> └───4.32 MB (11.85%) -- uncached
>     ├──2.25 MB (06.16%) -- vector/used
>     │  ├──2.24 MB (06.15%) ── source
>     │  └──0.00 MB (00.01%) ── decoded-heap
>     └──2.07 MB (05.69%) -- raster
>        ├──2.06 MB (05.65%) -- used
>        │  ├──1.79 MB (04.91%) ── source
>        │  └──0.27 MB (00.73%) ── decoded-heap
>        └──0.02 MB (00.04%) ── unused/source
> 
> 
> Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101
> Firefox/56.0 ID:20171024165158
> 
> I am also running (I think) version 59 on another PC/profile.

That looks like a completely reasonable amount for images, unless your workload makes you think those values are high for some reason?

Comment 6

[Timothy Nikkel (:tnikkel)]

Not sure this bug is actionable given comment 3 and comment 5. We need more information or steps to reproduce to even know if Firefox is acting in an unexpected way. Or if it is acting in the expected way but that is not deemed to be good enough.

Comment 7

[Worcester12345]

(In reply to Timothy Nikkel (:tnikkel) from comment #6)
> Not sure this bug is actionable given comment 3 and comment 5. We need more
> information or steps to reproduce to even know if Firefox is acting in an
> unexpected way. Or if it is acting in the expected way but that is not
> deemed to be good enough.

Comment 5 was mine, and might not be indicative of the problem. I may have been talking out my rear again. Thanks and sorry.

Comment 8

[Richard Newman [:rnewman]]

(In reply to Timothy Nikkel (:tnikkel) from comment #3)
> Generally we don't throw away the decoded image immediately, instead we let
> it expire. So what are the steps you are using here to reproduce?

STR:
* Open an image URL.
* Open another tab, so the image tab is not selected.
* Relaunch the browser. The image tab is a zombie.

Expected: 
* The image is cached on disk, but is not present in memory: I didn't click the tab to wake it up.

Actual
* The image for every tab, zombie or not, is present in memory immediately after startup.


Assuming I understand your comment correctly, tnikkel, I mean the opposite: this isn't to do with throwing away images, it's about not loading them in the first place, just as we don't load HTML until a tab becomes active.