Closed
Bug 621416
Opened 14 years ago
Closed 2 years ago
GC can't keep up with large allocations; only frees when ff is idle
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: dimaqq, Unassigned)
Details
Attachments
(1 file)
|
407 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b8) Gecko/20100101 Firefox/4.0b8
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b8) Gecko/20100101 Firefox/4.0b8
GC doesn't collect large allocations (here canvases) on time;
Below is html code that replaces a large canvas on button click; it should run in 100M. However, if there is user activity, GC doesn't appear to run and does not free old canvases.
If you click the button N times in a row, you can see N*100M of memory usage (task manager VM or top).
If you leave browser alone for 3~6 seconds, gc appears to run and soon memory usage drops back to 100M.
If you don't leave browser idle, e.g. move the mouse around the screen endlessly, memory doesn't get freed.
If you click the button too many times, firefox memory usage grows over system memory and system swaps heavily, resulting in 'application not responding' for several minutes.
This clearly doesn't work well for interactive applications, where periodic periods of inactivity are not expected (punintended).
Perhaps GC could be forced after large allocations? or GC could sense OS memory pressure?
Reproducible: Always
Steps to Reproduce:
1. load page (below)
2. click "eat mem" enough times, quickly
3. watch system swap, ff become unresponsive
Actual Results:
system swaps
Expected Results:
ff runs gc, frees old canvases, system doesn't swap, ff responsive throughout.
test page:
<html><head>
<script type="text/javascript">
function eat()
{
document.getElementById("c").innerHTML = "<canvas id='i' width='5000' height='5000'/>";
document.getElementById("i").getContext("2d").fillRect(0,0,5000,5000);
}
</script>
</head>
<body><form><input type="button" value="Eat mem!" onClick="eat()"/></form>
<p id="c">c</p></body></html>
notes:
occurs in 4.0b7 and latest 3.6.x;
also occurs in newest opera.
references:
real world example: bug 620883
also perhaps bug 619822
|
Reporter | |
Comment 1•14 years ago
|
||
|
||
Updated•14 years ago
|
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
|
|
||
Comment 2•14 years ago
|
||
Note that in this case it's not just GC, but CC that needs to run. Andreas, is the issue that we keep aborting CC if the mouse stays in motion?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I can confirm Dmitrii's "real world example" (speed.pypy.org/comparison/)
I am the author of that site, and I first I looked into completely removing the DOM element that contains the plot on every refresh. It is already done like that, but the memory is still not freed.
Sometimes, even if you visit another page, the memory is not freed, not even on closing the tab!
So it is definitely a problem in the way FF frees large memory allocations.
Some more notes:
I tested it with Kubuntu 10.04 64 bits and Firefox 3.6.12, so it is not exclusive to Windows XP either.
Chrome 5.0 does eat an extra memory chunk every time, but it does free it again after some time (20-40 seconds).
Also, Konqueror 4.4.2 with khtml and kjs (which maybe doesn't have such a modern and aggressive jit+gc), does NOT eat up memory. Every time you refresh the canvas, it frees up the memory taken by the old canvas.
|
Assignee | |
Updated•10 years ago
|
Assignee: general → nobody
|
||
Comment 5•7 years ago
|
||
Do you still see this issue when using a current version?
Flags: needinfo?(tobami)
Flags: needinfo?(dimaqq)
|
|
Reporter | |
Comment 6•7 years ago
|
||
Memory usage is no longer a problem w/ ff 58.0.1 on macOS 10.13.2.
CPU usage is pretty high for this test and OS shows wait cursor, but that's another problem.
Flags: needinfo?(dimaqq)
|
||
Updated•2 years ago
|
Severity: normal → S3
|
||
Comment 7•2 years ago
|
||
Clear a needinfo that is pending on an inactive user.
Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.
For more information, please visit auto_nag documentation.
Flags: needinfo?(tobami)
|
|
Reporter | |
Comment 8•2 years ago
|
||
The particular test case (creating a 5Kx5K canvas and filling it with solid color) no longer gobbled up memory today, 12 years later.
Tested with Mozilla Firefox 75.0 Linux x86-64.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•