678029 - TI: Memory regression for FOTN

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Gregor Wagner [:gwagner]]

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

Comment 1

[Andreas Gal :gal]

Thanks for checking this!

Comment 2

[Nicholas Nethercote [inactive]]

Did you keep the whole about:memory output?  TI has several memory reporters showing how much memory it's using.

Comment 3

[Brian Hackett [Laid off!]]

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.

Comment 4

[Mike Shaver (:shaver emeritus)]

Seems like valgrind should be able to spot this sort of leak -- set it running, get lunch, come back and see what it says?

Comment 5

[Brian Hackett [Laid off!]]

Attachment: caveman leak logging patch

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.

Comment 6

[Brian Hackett [Laid off!]]

Attachment: scraper

Script to scrape log files and find addresses of memory that has not been deallocated (yet).

Comment 7

[Brian Hackett [Laid off!]]

Attachment: patch

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

Comment 8

[Brian Hackett [Laid off!]]

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).

Comment 9

[Nicholas Nethercote [inactive]]

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.