678044 - TI: memory regression after closing all tabs

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Gregor Wagner [:gwagner]]

I was running my memBench with 150 tabs. The peak memory usage is 2.64GB with TI vs. 2.02 with MC.
More serious is the problem when I close all the tabs and my MemBench window. I can force a "Minimize memory" many times but the RealMem doesn't go below 1.65 GB.

TI after closing all tabs:
    0.00 MB -- canvas-2d-pixel-bytes
    0.50 MB -- gfx-surface-image
   74.82 MB -- heap-allocated
1,478.28 MB -- heap-unallocated
   74.82 MB -- heap-zone0-committed
1,539.10 MB -- heap-zone0-used
          2 -- js-compartments-system
          2 -- js-compartments-user
   53.00 MB -- js-gc-heap
    4.67 MB -- js-gc-heap-arena-unused
    0.00 MB -- js-gc-heap-chunk-clean-unused
   37.33 MB -- js-gc-heap-chunk-dirty-unused
     79.23% -- js-gc-heap-unused-fraction
      1,524 -- page-faults-hard
  2,539,011 -- page-faults-soft
1,687.88 MB -- resident
4,968.57 MB -- vsize

Comment 1

[Brian Hackett [Laid off!]]

How are you measuring peak memory usage?  What does the memory profile look like afterwards on m-c?

Comment 2

[Nicholas Nethercote [inactive]]

Full about:memory contents for both TI and MC after minimizing would be very helpful here :)

Comment 3

[Gregor Wagner [:gwagner]]

(In reply to Brian Hackett from comment #1)
> How are you measuring peak memory usage?  What does the memory profile look
> like afterwards on m-c?

With peak I mean the memory consumption with 150 open tabs. I don't have a profile from the m-c run but maybe your FOTN fix also fixed this problem.

Comment 4

[Gregor Wagner [:gwagner]]

(In reply to Brian Hackett from comment #1)
> How are you measuring peak memory usage?  What does the memory profile look
> like afterwards on m-c?

I basically was running the script from http://gregor-wagner.com/?p=79

Comment 5

[Brian Hackett [Laid off!]]

When I try to use this script Firefox opens about 25 pages and then refuses to open more windows, even if I tell Firefox not to block popup windows.  Is there some trick I need to know?

Comment 6

[Gregor Wagner [:gwagner]]

(In reply to Brian Hackett from comment #5)
> When I try to use this script Firefox opens about 25 pages and then refuses
> to open more windows, even if I tell Firefox not to block popup windows.  Is
> there some trick I need to know?

Oh there is a dom.popup_maximum option in about:memory

Comment 7

[Gregor Wagner [:gwagner]]

(In reply to Gregor Wagner from comment #6)
> (In reply to Brian Hackett from comment #5)
> > When I try to use this script Firefox opens about 25 pages and then refuses
> > to open more windows, even if I tell Firefox not to block popup windows.  Is
> > there some trick I need to know?
> 
> Oh there is a dom.popup_maximum option in about:memory

I mean about:config...

Comment 8

[Brian Hackett [Laid off!]]

Attachment: about:memory after opening 150 tabs

The verbose about:memory I get in a recent TI browser after using the script to open 150 tabs.  I get 2.1GB after opening the tabs, this is the 10.5 JM nightly (x64 by default I think?).  I used a script to add up the contribution from each component across all compartments (btw it would be cool if about:memory could do this).  This is after hitting the GC button, but I also got the numbers before the GC and they are similar except for ~50MB of extra transient pool allocation.

38088960 :: object-main
40273792 :: gc-heap-chunk-unused
55024936 :: script-main
64588800 :: property-tables
71637635 :: raw
78571423 :: used
80448792 :: content
80784624 :: images
86428704 :: arena-unused
95982760 :: type-inference
139124736 :: mjit-code
157801792 :: shapes
161501329 :: arenas
161814481 :: layout
180774502 :: scripts
225669936 :: objects
505872128 :: gc-heap
723484876 :: heap-unclassified
1130771131 :: js
2125815664 :: explicit

96MB type-inference includes 55MB script-main, 38MB object-main, and 3MB of typeset data.  This is 4.5% of 'explicit'.  Once we start discarding observed types in scripts before trashing the script itself, type inference data should be about 1.8% of 'explicit'.  (Need to do this soon.... also could eventually integrate with bug 678037 observations and revert scripts not used in a while to their raw source).

So I'm not sure why you're seeing such a large difference between m-c and TI here, though posting similar about:memory data would be good.

One possibility is that even while loading the tabs you're seeing the fragmentation problem which you're getting after closing the tabs.  I wasn't able to observe if I get this problem (my browser went into conniptions while mass-closing the tabs), but from your numbers in comment 0 about 90% of the memory is in heap-unallocated (1.48GB out of 1.69GB), which suggests that the heap allocator is having trouble releasing resources because random little things haven't been freed yet.

The FOTN leak fix may have helped this (not sure how prevalent typed arrays are yet), but there are still a fair number of little malloc'ed things which TI holds onto: all the script-typeset and object-typeset data is malloc'ed, along with a fair amount of object-main data (haven't measured).

Adding two or three more GC arena kinds to hold this data should help/fix any TI-induced fragmentation here, but my heap also had 31MB of malloc'ed object slots (larger size than all malloc'ed TI data, though probably fewer individual allocations) and m-c should suffer from this problem to some degree too.  A more general solution may be needed.

Comment 9

[Brian Hackett [Laid off!]]

Attachment: mozilla-central about:memory, with 150 tabs open

Comment 10

[Brian Hackett [Laid off!]]

Attachment: mozilla-central about:memory, after closing 150 tabs

Comment 11

[Brian Hackett [Laid off!]]

Attachment: type-inference about:memory, with 150 tabs open

Comment 12

[Brian Hackett [Laid off!]]

Attachment: type-inference about:memory, after closing 150 tabs

Comment 13

[Brian Hackett [Laid off!]]

The mozilla-central numbers above are from the 8/16 nightly, the TI numbers are with the patch in bug 679329 applied.  I tried to make these runs as similar as possible:

1. start Firefox clean, open MemBench and open the 154 tabs
2. wait a few minutes until after all tabs have loaded (90 seconds is not enough for me)
3. run about:memory, do a GC and collect data

Despite this, there is still significant variation in how the runs behaved.  The m-c 'explicit' is 2044MB, while the TI 'explicit' is 1834MB, 11% better.  I think this difference is mostly due to happenstance --- other numbers that should be stable across versions of the browser, like JS object data, are also 8-10% better on TI.

So I think trying to compare overall memory usage with runs like this is problematic and not really apples-to-apples.  We need better techniques for benchmarking memory usage.  However, this is still good for using about:memory to compare memory consumption for particular categories within and across runs, as differences there are starker.  To that effect:

- With 150 tabs open, type inference data accounts for 36.5MB, or 2% of explicit.

- The TI run used 108MB less space for mjit data by throwing jitcode away more aggressively, so that even without the variation across runs TI should be a net improvement over m-c.  Though we should also be throwing jitcode away aggressively with TI disabled, as the 1/8 lifetime thing we do to discard jitcode in such cases is slow, and was conceived when methodjit_always was the default/only option.

- The ratio of mjit-code / mjit-data is much higher on the TI run.  I think most of the mjit-code data here (119MB, more than 3x the TI data) is for eagerly compiled regexps.

- Ratio of JS objects to JS scripts is the same between runs, so I think the discrepancies in how many GC things are created is gone.

- Ratio of JS objects to JS object malloc'ed slots is somewhat better on TI (7x m-c vs. 9x TI), so I think adaptive sizing of JS objects created with 'new' has an effect on real websites.

Also, after closing all tabs m-c and TI have about the same memory usage, and both suffer to a great degree from fragmentation in the heap allocator.  Bug 679329 got rid of pretty much all small heap allocations by TI; I don't know whether TI was contributing to this fragmentation before, but I'm pretty sure it no longer has an effect.

Comment 14

[Gregor Wagner [:gwagner]]

Great progress!

(In reply to Brian Hackett from comment #13)
> 
> 2. wait a few minutes until after all tabs have loaded (90 seconds is not
> enough for me)

I also noticed this today. MC usually finishes after 10 - 20 sec and some sites just keep loading on TI.

Comment 15

[Brian Hackett [Laid off!]]

(In reply to Gregor Wagner from comment #14)
> Great progress!
> 
> (In reply to Brian Hackett from comment #13)
> > 
> > 2. wait a few minutes until after all tabs have loaded (90 seconds is not
> > enough for me)
> 
> I also noticed this today. MC usually finishes after 10 - 20 sec and some
> sites just keep loading on TI.

I get this behavior with both TI and MC.  Again, I think there is considerable variance across runs which is not being controlled for by this testing mechanism.

Comment 16

[Gregor Wagner [:gwagner]]

(In reply to Brian Hackett from comment #15)
> (In reply to Gregor Wagner from comment #14)
> > Great progress!
> > 
> > (In reply to Brian Hackett from comment #13)
> > > 
> > > 2. wait a few minutes until after all tabs have loaded (90 seconds is not
> > > enough for me)
> > 
> > I also noticed this today. MC usually finishes after 10 - 20 sec and some
> > sites just keep loading on TI.
> 
> I get this behavior with both TI and MC.  Again, I think there is
> considerable variance across runs which is not being controlled for by this
> testing mechanism.

Yeah I also got this behavior now on MC.

Comment 17

[Nicholas Nethercote [inactive]]

bhackett: that's really impressive.  I'm totally happy, from a memory consumption POV, for TI to land now.  Great work!