Closed Bug 623072 Opened 12 years ago Closed 12 years ago



(Firefox for Android Graveyard :: General, defect)

Not set



Tracking Status
fennec 2.0b4+ ---


(Reporter: dougt, Assigned: dougt)



(Keywords: memory-footprint)


(2 files)

Recently, JSGC_MAX_MALLOC_BYTES was increased to 80mb.  I added support to make this configurable.  The original value was 32mb.  The difference between 40 and 20 makes little difference in terms of memory usage, but does slow down ss.  The following patch sets JSGC_MAX_MALLOC_BYTES to 40mbs.
Attached patch patch v.1Splinter Review
tracking-fennec: --- → 2.0b4+
Comment on attachment 501194 [details] [diff] [review]
patch v.1

this patch will cause perf regressions over benchmarks due to more frequent gc as memory rises.
Attachment #501194 - Flags: review?(mark.finkle)
Comment on attachment 501194 [details] [diff] [review]
patch v.1

So if I understand correctly, we are currently running with a high_water_mark = 32 and I don't see any negative effect on the Tsunspider talos test. Why not just keep it at 32?
default  is 80.
mfinkle, the existing code, when 32 was set, would force the watermark to actually be 80 and the max allocation to be -1 (inf).
Depends on: 613551
Keywords: footprint
OS: Linux → All
Hardware: x86_64 → All
show should we just set this to 32 and try it?
Sounds fine.  r+ on that change?
Comment on attachment 501194 [details] [diff] [review]
patch v.1

r+ for setting it to 32 to start with
Attachment #501194 - Flags: review?(mark.finkle) → review+
Closed: 12 years ago
Resolution: --- → FIXED
doug, anything we need to look out for when testing this fix?   stability? oom? perf?
memory usage should be lower when compared to builds without this change.
Ran a handful of startup tests, open tabs, and running extensions on on the 1/10 nightly vs fennec beta 3.  The nightly seemed to consistently display lower memory usage (using process manager app).   

marking verified on Mozilla/5.0 (Android; Linux armv71; rv:2.0b9pre) Gecko/20110110 Firefox/4.0b9pre Fennec/4.0b4pre	

Can someone verify this against maemo builds?
How can be verified this on maemo?
You need to log in before you can comment on or make changes to this bug.