Closed Bug 678029 Opened 9 years ago Closed 9 years ago
TI: Memory regression for FOTN
I just compared Flight of the Navigator MC and TI. MC has at the end of the video about 620MB and TI about 1.26GB even after forcing some GCs (when the credits are shown at the end of the video). Something seems to be leaking. about:memory shows: MC Real Mem:620MB 15.85 MB -- canvas-2d-pixel-bytes 5.57 MB -- gfx-surface-image 173.36 MB -- heap-allocated 61.38 MB -- heap-unallocated 173.35 MB -- heap-zone0-committed 220.75 MB -- heap-zone0-used 2 -- js-compartments-system 2 -- js-compartments-user 182.00 MB -- js-gc-heap 20.75 MB -- js-gc-heap-arena-unused 9.00 MB -- js-gc-heap-chunk-clean-unused 50.30 MB -- js-gc-heap-chunk-dirty-unused 43.98% -- js-gc-heap-unused-fraction 864 -- page-faults-hard 672,780 -- page-faults-soft 550.30 MB -- resident 4,101.64 MB -- vsize 143 -- webgl-buffer-count 3.21 MB -- webgl-buffer-memory 2 -- webgl-context-count 1 -- webgl-renderbuffer-count 8.00 MB -- webgl-renderbuffer-memory 26 -- webgl-shader-count 57 -- webgl-texture-count 57.41 MB -- webgl-texture-memory TI: Real Mem: 1.26GB 15.80 MB -- canvas-2d-pixel-bytes 5.57 MB -- gfx-surface-image 918.11 MB -- heap-allocated 70.11 MB -- heap-unallocated 918.06 MB -- heap-zone0-committed 975.22 MB -- heap-zone0-used 2 -- js-compartments-system 2 -- js-compartments-user 174.00 MB -- js-gc-heap 22.78 MB -- js-gc-heap-arena-unused 0.00 MB -- js-gc-heap-chunk-clean-unused 46.94 MB -- js-gc-heap-chunk-dirty-unused 40.06% -- js-gc-heap-unused-fraction 18 -- page-faults-hard 788,301 -- page-faults-soft 1,226.56 MB -- resident 4,862.95 MB -- vsize 143 -- webgl-buffer-count 3.21 MB -- webgl-buffer-memory 2 -- webgl-context-count 1 -- webgl-renderbuffer-count 8.00 MB -- webgl-renderbuffer-memory 26 -- webgl-shader-count 57 -- webgl-texture-count 57.37 MB -- webgl-texture-memory
Thanks for checking this!
Did you keep the whole about:memory output? TI has several memory reporters showing how much memory it's using.
I can repro this. I didn't see anything significant in the memory reported in use for TI structures, and the GC heap size is about the same with/without TI, so I'm guessing this is a straight up memory leak. Do we have a good way of figuring out memory usage in such long running tests? I've been trying to use the backtrace() function to log mallocs/frees from JS along with the malloc() stacks, not sure yet if I can make this not-horribly-slow.
Seems like valgrind should be able to spot this sort of leak -- set it running, get lunch, come back and see what it says?
Patch logging calls to js_malloc / js_free and friends, with stacks. I haven't had a lot of luck getting valgrind to work in the browser (though I haven't tried hard), but this worked to track the leak down (details in a bit). For each js_malloc it reports the result/size, and uses the BSD/Linux backtrace() to get the top N entries on the stack. dladdr() can find the symbol name for that address, though it is only printed the first time each distinct address appears (dladdr() seems to have a huge overhead). js_free() reports the pointers being freed, and then the log is scraped to find the amount of memory still live and where it was allocated. This needs to be a debug build to get accurate stacks, but doesn't seem to impose significant overhead on top of that. Attaching for future reference, and so I don't lose it.
Script to scrape log files and find addresses of memory that has not been deallocated (yet).
Restore m-c behavior of using obj->slots to store ArrayBuffer data. This came in on a merge and messed with the slots invariants wrt the different object layout in TI vs. m-c, so I moved it to a fixed slot. This caused it to never get freed, because ArrayBuffer has no finalizer and JSObject::finish will only pick up on malloc'ed data stored in obj->slots. This patch makes the ArrayBuffer layout work like m-c, shuffles some things into JSObject members to allow accesses on private data and adds comments explaining what's going on. http://hg.mozilla.org/projects/jaegermonkey/rev/e5de9834cd18
Also, after fixing this the amount of live JS stuff after FOTN went from ~500MB to ~13MB, presumably for stuff that is still live (this approach can't distinguish reachable from unreachable data).
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
https://developer.mozilla.org/en/Debugging_Mozilla_with_valgrind is a nice description of all the magic switches (in both Valgrind and Firefox) that you need for a good experience. http://blog.mozilla.com/nnethercote/2011/01/07/memory-profiling-firefox-with-massif-part-2/ is also useful if you want to try using Massif.
You need to log in before you can comment on or make changes to this bug.