It was a good week for MemShrink.
- New: “runtime/threads/temporary” counts various pieces of short-lived data, mostly parse nodes. It sometimes spikes up to multiple MBs.
- New: “runtime/threads/normal” measures thread data on the heap that isn’t covered by “runtime/threads/temporary”. It’s normally a few 100s of KBs.
- New: “runtime/contexts” measures JSContexts and various related structures, which usually account for a few 10s or 100s of KB.
- New/fixed: “runtime/threads/regexp-code” measures code generated by the regexp compiler. This was previously measured under “mjit-code/regexp” but that reporter was broken recently when the location of this generated code was moved, so I fixed it.
- Fixed: “runtime/atoms-table” and “runtime/runtime-object” are existing reporters that together often account for up to 4.5MB. They were incorrectly marked as measuring non-heap memory instead of heap memory, meaning that the “explicit” and “heap-unclassified” totals were both incorrectly inflated by that amount. While fixing this, I also confirmed that we weren’t making the same mistake with any of our other memory reporters.
- Renamed: “runtime/threads/stack-committed” was previously called “stack-size”. I renamed it to go with the other “runtime/threads” reports because that’s where it conceptually belongs.
I also added a memory reporter for XPConnect. It typically accounts for 1MB or more.
I have a lot more work in the pipeline to improve the coverage and correctness of memory reporters. More about this in the coming weeks as I land the relevant patches!
Joel Maher got RSS memory measurements working for Android on Talos, Mozilla’s performance regression testing suite. This was a MemShrink:P1 bug. Graphs of the live data can be seen here.
Here’s the current bug count.
- P1: 27 (-1/+1)
- P2: 141 (-3/+5)
- P3: 62 (-1/+2)
- Unprioritized: 0 (-0/+0)
Only three more MemShrink bugs than this time last week! Pretty good.