Open
Bug 1421966
Opened 7 years ago
Updated 2 years ago
Investigate triggering compaction if the proportion of unused GC things gets too high
Categories
(Core :: JavaScript: GC, enhancement, P3)
Core
JavaScript: GC
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox59 | --- | affected |
People
(Reporter: jonco, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [MemShrink:P2])
I just saw this line from an about:memory dump go by: │ │ │ ├──1,464.95 MB (36.98%) ── unused-gc-things This is pretty high. We should compute this value after sweeping and perform compacting if it's greater than some threshold, even if compacting was not requested.
Updated•7 years ago
|
status-firefox59:
--- → affected
Priority: -- → P3
Comment 1•6 years ago
|
||
I see things like that frequently, as well as other site "leaks". Random case with washingtonpost: │ │ │ ├──1,006.19 MB (45.53%) ── unused-gc-things after sitting for a few hours in an article. Even forced GC and CC from about:memory don't recover it; only Minimize (of course)
Whiteboard: [MemShrink]
Updated•6 years ago
|
Whiteboard: [MemShrink] → [MemShrink:P1]
Comment 2•6 years ago
|
||
Jon, are there any plans to work on this? Do we still need it?
Flags: needinfo?(jcoppeard)
Whiteboard: [MemShrink:P1] → [MemShrink:P2]
Comment 3•6 years ago
|
||
I'm interested in working on this, Can we aim it for 67? Jon, we can discuss the priority of this with other stuff.
Reporter | ||
Comment 4•6 years ago
|
||
Yes we should do this. Paul, that sounds good. We'll have to be careful we don't increase the slice overrun time too much because compacting is not very incremental right now.
Flags: needinfo?(jcoppeard)
Reporter | ||
Updated•6 years ago
|
Blocks: GCScheduling
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•