AWSY: ~1.7 MB regression in resident memory usage on July 25




Firefox for Android
5 years ago
5 years ago


(Reporter: kats, Unassigned)


23 Branch
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment)

The top graph at shows a ~1.68 MiB regression in the "Start" line and a 1.38 MiB regression in the "StartSettled" line. Looking at the detailed about memory dumps this appears to be mostly just more of libxul being loaded on startup. I'm not yet sure if libxul actually got bigger or we're just loading more of it. Note that the explicit memory usage has not increased noticeably, it's just the resident amount that went up.

28c8c52f176239d85aee297031d0809be49055cd 121.36MiB
9308a970daee28e4431da34b1d3e258524db4337 123.03MiB Δ 1,716.00KiB

Start Settled:
28c8c52f176239d85aee297031d0809be49055cd 138.24MiB
9308a970daee28e4431da34b1d3e258524db4337 139.62MiB Δ 1,412.00KiB

The pushlog range is pretty small and implicates bug 894448:
Could this be related to the increase in static initializers?
Libxul itself appears to have gotten a little smaller in that range:

at 28c8c52f176239d85aee297031d0809be49055cd: is 12895864 bytes inside the APK
at 9308a970daee28e4431da34b1d3e258524db4337: is 12891533 bytes inside the APK
re: comment 1
Flags: needinfo?(mh+mozilla)
Yes, it can very much. A good way to know is to set the MOZ_DEBUG_LINKER environment variable to 1 when starting fennec, and check the "n/m chunks decompressed" lines.
Flags: needinfo?(mh+mozilla)
Created attachment 782791 [details]
"chunks decompressed" output with MOZ_DEBUG_LINKER=1

"old.log" corresponds to the build prior to the changes, and "new.log" corresponds to the build with the changes. More chunks do appear to be loaded from even at the oneLibLoaded output.
At the firstLoadURI mark, there's a difference of 43 chunks. A chunk is 16KiB. That's 688KiB.

Other things happen after firstLoadURI, though, but i wouldn't expect it to make a big difference. So that accounts for some of it, but not all of it.
Ah, it's a RSS count. Then since there are two mappings of the same data, RSS will count those 688KiB twice. That's 1376KiB.
Bug 899368 appears to have fixed this. There is a drop in memory usage in this (large-ish) range:

which includes the patch from 899368.

770b97caaababc0feb961b4cc8d9812f15b88dc6 125.32MiB
5d56f5be9d3fbd3773e43f5dc42e03ef70b73679 123.11MiB Δ -2.21MiB

Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.