Fall out from bug 445923. We currently run out of memory when running the Dromaeo tests.
In my opinion, we should decide how much memory SpiderMonkey can use on mobile device, for example, 5 MB, 6 MB and so on. In order words, we need to make a threshold for SpiderMonkey. Internally, SpiderMonkey has two counters (gcMallocBytes, gcBytes) in order to monitor the memory allocated by JS_malloc() and allocated by NewGCArena(). It seems to me we can implement the dialog using those counter variables.
I tried to implement my idea which was mentioned in Bug 445923 Comment #4. I can control a peak memory and reduce a bit memory consumption. But, page loading time is more slower because GC is called more frequently. This is a trade-off between memory and speed. If we can reduce the GC cost, I think this idea can be helpful to fennec. And it seems this idea can be combined with this bug. Test scenario is 1. Run firefox on N810 2. Access google home (http://www.google.com/en) 3. Search for "spidermonkey" keyword. 4. Open 7 tabs in the searching result. 5. Close firefox. And, below numbers show only a memory size allocated by NewGCArena(). Below result doesn't include a memory size consumed by JS_malloc(). I don't know how can I control a memory consumed by JS_malloc() yet. Test Result is as below, - Normal Firefox * Total # of GC call : 53 times * Total used memory : 6.9 MB * Peak size of memory : 3.5 MB - Firefox with this idea * Total # of GC call : 62 times * Total used memory : 5.2 MB * Peak size of memory : 2.0 MB
thanks for looking in to this. we should talk to the JS guys and see if we can GC a bit more frequently
Assignee: nobody → doug.turner
Target Milestone: --- → Fennec A3
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → All
Hardware: PC → All
brad, do you see this with your jemalloc patch?
This works fine for me on N900 and N1
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.