(This was originally bug 693404, but that one has morphed into a different issue.)
jemalloc is currently disabled on Mac due to a TP5-RSS regression, bug 670492.
I think this regression is bogus. We can use the work in bug 693404 to determine whether the regression is real or not.
Once we've definitively established whether jemalloc on 10.5 is a memory win, I think we should consider enabling jemalloc on 10.5, even before we get Talos set up to measure memory usage on 10.5 properly, because jmaher says it may take months to change Talos (bug 693404 comment 17).
I'm not sure this is worth working on, given that Apple has stopped issuing security updates for Mac OS X 10.5.
Can we get some data about how many users are on 10.5?
I think so long as we won't check something in if it regresses 10.5, we should consider taking this. It's not a hard thing; in theory, anyway, we just need to flip a switch.
Created attachment 569983 [details] [diff] [review]
I just tested on the 10.5 machine we have in the office.
Test case: Open techcrunch, cnn. Close both tabs. Open about:memory, click minimize memory usage.
Latest trunk: 120mb.
With jemalloc enabled: 105mb.
We'll need to write to dev.tree-management before we push this, since it's going to look like a big regression.
Comment on attachment 569983 [details] [diff] [review]
Review of attachment 569983 [details] [diff] [review]:
Well that was easy.
Awesome, this was an 8% TP5 win.
I see this:
Talos Regression :( Tp5 MozAfterPaint (RSS) increase 18.4% on MacOSX 10.5.8 Mozilla-Inbound
Followed by this:
Talos Improvement! Tp5 MozAfterPaint decrease 7.93% on MacOSX 10.5.8 Mozilla-Inbound
Right. The RSS regression is expected and bogus. The TP5 speed improvement is neither. :)
This is a big change that we should track for FF10.
Unfortunately we're going to have to back this out of FF10, due to what appears to be an OS-level bug. Bummer.
Discussion has been in bug 702250.