Multiple reports of long periods of unresponsiveness with long COMPARTMENT_REVIVED GC
Categories
(Core :: JavaScript: GC, defect, P3)
Tracking
()
People
(Reporter: glob, Unassigned)
References
(Blocks 1 open bug)
Details
I've had multiple reports of long periods of unresponsiveness, sadly without clear steps to reproduce.
Summary of the reports:
- gets slow and starts hanging, restarting Firefox fixes it until it happens again
- about:processes doesn't point to a specific tab
- CPU pegged at 100%
- developing a react app makes this noticeably worse
A profile snapshot points to a massive amount of GC.
|
||
Comment 2•9 months ago
|
||
It looks like this is a 17 second COMPARTMENT_REVIVED GC.
|
|
||
Comment 3•9 months ago
|
||
Also, it is in the parent process.
|
|
||
Updated•9 months ago
|
|
||
Comment 4•9 months ago
|
||
This is showing a 3.8GB heap in the parent process, which is extremely large (from telemetry the median is 40MB and 95th percentile is 85MB). I wonder if there is a memory leak happening.
Even so, this is very slow for a full GC. I'm not sure what's happening here.
(In reply to Jon Coppeard (:jonco) from comment #4)
This is showing a 3.8GB heap in the parent process, which is extremely large (from telemetry the median is 40MB and 95th percentile is 85MB). I wonder if there is a memory leak happening.
Even so, this is very slow for a full GC. I'm not sure what's happening here.
I reported this orginally, let me know if there's more info I can provide. I've been seeing this for a while now. It feels like a memory leak from the user experience, but I never found other people reporting it online so I figured it must be something unique to my setup.
|
|
||
Comment 6•9 months ago
|
||
(In reply to github from comment #5)
Can you post an about:memory memory report (at least the part for the parent process)? That might have some clues.
I captured a memory report today. While that was happening Firefox became unresponsive and I had to Force Quit it. I've included in the zip file the crash report MacOS produced, in case that's helpful:
https://filebin.net/yb4kpx6xe2eegmh0
Please let me know if there's more info I can provide.
|
|
||
Comment 9•9 months ago
|
||
(In reply to tom from comment #8)
Thanks for the report. The main thing that jumps out is that there is over 3GB of string data present.
If you select 'verbose' and press 'Measure' then about:memory will also show the largest strings. You can find these with Ctrl-F + "string(length". These may contain private data so you probably don't want to post this output. However they may point to what is causing the problem, for example if an extension has gone haywire creating strings this may indicate which one.
|
||
Comment 10•9 months ago
|
||
OK I will try that next time. I'm guessing it will be something to do with how React/NextJS is doing fast refresh (I was working on an app as this occurred, and that's a common way I see this problem come up).
Is this something that you would hope to get resolved, or should I expect behaviour to stay unchanged in the medium term?
Thanks
|
|
||
Comment 11•9 months ago
|
||
(In reply to tom from comment #10)
There's not a lot to go on here sadly.
|
|
||
Comment 12•9 months ago
|
||
I just had a look at the strings dumped by capturing a "verbose" measurement during a period where Firefox was experiencing this behaviour. The total sum of the "length"s listed in the path is 42907297. Assuming this length is in bytes, dividing by (1024*1024) to convert from bytes to MB, it looks like it's only ~40MB of strings.
Would there be something else to look at here?
|
|
||
Comment 13•9 months ago
|
||
Also I was surprised to find content from Private Browsing windows still in memory, even though these Private Browsing windows were closed a long time ago. Is that expected?
|
|
||
Comment 14•9 months ago
|
||
(In reply to tom from comment #13)
That would indicate some kind of memory leak. Unfortunately I can't tell much more than that.
Description
•