Open Bug 1435016 Opened 2 years ago Updated 2 years ago

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

Categories

(Core :: ImageLib, defect, P3)

x86_64
macOS
defect

Tracking

()

REOPENED
Tracking Status
firefox60 --- affected

People

(Reporter: rnewman, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: memory-footprint, Whiteboard: gfx-noted)

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.
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.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
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
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Blocks: image-suck
Component: Untriaged → ImageLib
Product: Firefox → Core
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?
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.
(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?
Whiteboard: gfx-noted
Priority: -- → P3
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.
(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.
(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.
You need to log in before you can comment on or make changes to this bug.