MEMORYSTATUSEX.ullAvailPageFile tells us how much space is available in physical memory plus the page file. When this gets to 0, Windows will not let us map any more memory. So we should raise a low-memory event before we get here.
See also bug 720444, where we added ullAvailPageFile to crash reports.
Assignee: nobody → justin.lebar+bug
Summary: Monitor ullAvailPageFile on Windows and fire a low-memory event when it gets low → Monitor ullAvailPageFile on Windows and fire a memory-pressure event when it gets low
I need to add a line to telemetryping.js to send this memory reporter.
Attachment #603434 - Attachment is obsolete: true
Try run for 5377fc9154a5 is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=5377fc9154a5 Results (out of 50 total builds): success: 40 warnings: 8 failure: 2 Builds (or logs if builds failed) available at: http://email@example.com Timed out after 06 hours without completing.
Landed on m-i https://hg.mozilla.org/integration/mozilla-inbound/rev/b2ac02d89f41 but this had the wrong bug number (gah), so backed out and re-landed https://hg.mozilla.org/integration/mozilla-inbound/rev/37441c99ccf1 https://hg.mozilla.org/integration/mozilla-inbound/rev/cad7f1ab3594
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
I think this might be covered elsewhere, but I can't find it. Why is the checking for low physical, commit and virtual memory Windows-only?
(In reply to Daniel Cater from comment #8) > I think this might be covered elsewhere, but I can't find it. Why is the > checking for low physical, commit and virtual memory Windows-only? Because it's hard(er) to do elsewhere, and because it's not a clear win on Windows, so we wanted to do it there before wasting our time elsewhere. Also, Windows machines are much more likely to be running a 32-bit Firefox than Mac or Linux. https://bugzilla.mozilla.org/show_bug.cgi?id=664291
You need to log in before you can comment on or make changes to this bug.