620883 - Insane memory consumption with jqplot library; grinding/swapping/unresponsive

Status: RESOLVED INVALID

(Core :: General, defect)

Description

[Dima Tisnek]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7

I get 350M memory usage from a single tab with a single long plot;
Memory usage is proportional to window (and thus plot) area;
As virtual memory grows over certain threshold (close to sys memory)
Firefox grinds heavily, uses disk a lot (swaps?) and is unresponsive for several minutes.

After period of grind, browser recovers more or less;
Sometimes after period of grind browser pops up "script is taking too long..."

Part of the problem could be the library
Part of the problem could be caching/storage of graphics primitives
Part of the problem could be garbage collection

For the imatient, this is a bad as a browser crash.

Reproducible: Always

Steps to Reproduce:
1. go to url http://speed.pypy.org/comparison/
2. tick "horizontal"
3. watch memory
4 (opt) tick the boxes on the left, plot is redrawn, yet new memory is wasted all the time.
Actual Results:  
memory usage in "horizontal" mode at 1680x1050 window size 350M;
every tick in the column selector kicks memory up ~200M;
when used mem gets close to system total, a period of grind starts

Expected Results:  
Firefox protects user from bad scripts (if this is the case), or
Firefox manages memory better

Note: same problem with stable firefox 3.x, opera 11, but with notably shorter grind duration; ie8 does not suffer from same (why?)

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

Seeing the same Behavior with Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20101222 Firefox/4.0b9pre ID:20101222030351 (http://hg.mozilla.org/mozilla-central/rev/b0c6a324e72f):

With "horizontal" checked:

* Site Navigation (e.g. Scrolling/Drop-Down Selection) is non-snappy/laggy.
* changing the Executables/Benchmark Settings on the left takes its Time.
* Rise of Memory Consumption if you change the above mentioned Settings.

Comment 2

[Boris Zbarsky [:bzbarsky]]

This sounds like just a bug in the site, at first glance.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> ie8 does not suffer from same (why?)

Because there's browser-sniffing all over here?  Just grep for |if (h.browser.msie)| in jquery.jqplot.min.js.

Comment 4

[Boris Zbarsky [:bzbarsky]]

So what I see this page do, in horizontal mode, is create 17 canvases each of which is width="816" height="3587".  That means that each of them has a backing store of 816*3587*4 = 11,707,968 bytes.  So that's about 200MB of memory usage right there.

I have no idea why they feel a need for 17 huge canvases, but if they want them, that's how much memory they'll take...

Comment 5

[Dima Tisnek]

Well I figured the plotting library was at fault here, still

Is there nothing firefox can do to protect users from bad JS here?

Comment 6

[Boris Zbarsky [:bzbarsky]]

We have no way to even tell the JS is "bad".  It's just using a few hundred megs of RAM.  That's not a crime, per se...

Comment 7

[Dima Tisnek]

I'm not saying it's trivial,

yet a situation where one tab/site can bring ff with tens of other tabs/sites open to its knees is not very good, is it?

also the way ff 4.0b7 in particular grinds on this site is quite bad, although I tend to think that's an unrelated issue, for example, b7 (ext and plug disabled) takes very long to exit, it's faster to open task manager and stop firefox process than wait (or switch to term and killall on linux).

p.s. can you see that old canvases are freed or remain when you select/unselect data columns (tickboxes on the left)?

I can't tell if that too is jqplot bug or ff weirdness, but memory footprint grows with every change.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> yet a situation where one tab/site can bring ff with tens of other tabs/sites
> open to its knees is not very good, is it?

Sure; the right solution to that is per-site processes.  Being worked on!

> p.s. can you see that old canvases are freed or remain when you select/unselect
> data columns (tickboxes on the left)?

They get freed eventually, but not immediately, as in any garbage collected system.

Comment 9

[Dima Tisnek]

Actually I considered a chance this was a gc "bug/feature",

My understanding of the grind is that in order to free the old canvases, gc has to go through other objects to determine that said canvases are not referenced anyore (depending what gc type is used). If the system already swaps, this traversal becomes very expensive, as it needs to get swapped out pages back.

If I got that right then:
Large objects in gc must be more sensitive to memory pressure, or
GC thread ought to have higher priority than mutators, or
Mutators must be penalized for large allocations

Perhaps rename this bug?

Comment 10

[Dima Tisnek]

I submitted a separate bug report 621416 for the GC issue.