Closed Bug 2007841 Opened 10 months ago Closed 5 months ago

Cached inline stylesheets do not release memory even after reloading the page and manually reducing memory

Categories

(Core :: CSS Parsing and Computation, defect)

defect

Tracking

()

RESOLVED FIXED
153 Branch
Tracking Status
firefox-esr115 --- unaffected
firefox-esr140 --- wontfix
firefox146 --- wontfix
firefox147 --- wontfix
firefox148 --- wontfix
firefox151 --- wontfix
firefox152 --- wontfix
firefox153 --- fixed

People

(Reporter: mayankleoboy1, Assigned: emilio)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(2 files, 1 external file)

This is the testcase from bug 1962946

STR:

  1. Open testcase
  2. Enter 2000 in the input-box
  3. Click on run. Wait for the page to get responsive which will take ~5s.
  4. Now hard reload the page (CTRL+SHIFT +R)
  5. Go to about:memory and click on "Manually reduce memory"

AR: in steps #4 and steps#5, the memory is not reduced
ER: It should?

The memory would go down before bug 1956486. So i am marking it as a regressor.

Flags: needinfo?(emilio)

Set release status flags based on info from the regressing bug 1956486

This does seem somewhat leak-ish; by repeating the steps (after force-reloading the test page), the reported memory usage increases further (and generating the about:memory report gets a lot slower).

Navigating away from the test page does result in the memory being released, it seems. Still, it looks like as long as we're on the test page (even after force-reloading and running minimize-memory), stale cached stuff is being a bit persistent.

Severity: -- → S3
See Also: → 2039484
Duplicate of this bug: 2039484

This is a much simpler testcase that repros the issue.

STR:

  1. Open testcase
  2. Click Generate
  3. Click Nativeclear
  4. Force-reload the page
  5. Go to about:memory and click on "Mnually free memory"

AR: Memory is not freed
ER: it should

I made it a global thing rather than something more subtle like
nsExpirationTracker, because nsExpirationTracker doesn't deal super-well
with the nested hashtable structure and different kinds of entries, and
this seems like it should be good enough (idle runnable + delay).

Much like the atom table GC:

https://searchfox.org/firefox-main/source/xpcom/ds/nsAtomTable.cpp#456

Assignee: nobody → emilio
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 153 Branch
Flags: needinfo?(emilio)

This is fixed in nightly.
Profile: https://share.firefox.dev/4o4KWkw

Regressions: 2045074
Blocks: 1958705
QA Whiteboard: [qa-triage-done-c154/b153]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: