If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

methodjit scripts only after they have executed at least N entries or loop iterations

RESOLVED DUPLICATE of bug 631951

Status

()

Core
JavaScript Engine
RESOLVED DUPLICATE of bug 631951
7 years ago
7 years ago

People

(Reporter: dmandelin, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
See 631581 for measurements suggesting this will solve all of our JM memory problems. (Also measurements by Luke that aren't in a bug.) It is expected to cut methodjit memory usage 5-10x, and also make web sites a hair faster.
(Reporter)

Comment 1

7 years ago
As with bug 631706, the important question right now is, do we want to try this for Fx4?

Main benefits:

+ Cuts jitcode memory usage by *roughly* estimated 5-10x in browser
+ Cuts total browser memory usage by *roughly* estimated 5-20%.

Main risks:

- May regress SunSpider performance. I think mostly SunSpider doesn't have,
  small loops, so this may be a losing strategy there. Maybe we'd lose very
  little, or maybe we'd have to come up with some clever way to compiler sooner
  in that scenario. Long-term, we should work around that, but for Fx4 I think
  we just have get the best score we can.
- Counters may regress performance. We'd need to spend extra time counting up.
  This is probably not too bad, though.
- May introduce bugs. I think it's still fairly simple, though.
You can probably guess what I will say, but I'll say it anyway.

I think this is worth getting into Firefox 4.0 *even if it requires an extra beta that otherwise wouldn't be needed*.  But it's looking like there'll be a beta 12 anyway, so it may not come to that.

I say this because Firefox already has a reputation for memory bloat, deserved or not.  If we release 4.0 and our method JIT memory usage is 3x Chrome's, we'll be hard-pressed to ever shake that reputation.

As for Sunspider... I think a lot of people understand that it's pretty meaningless now, all the browsers are within 10% or 20%.  So I'd personally be willing to sacrifice some speed there... maybe up to 5%?  (Waves hands.)  On AWFY we're currently 1.12x faster than Chrome.
Let's not trade away anything yet. We don't know if there's a SS regression in a simple change here that saves lots of mem. So it seems worth developing a patch, in order to measure the effects and address the risks raised in comment 1.

/be
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 631951
You need to log in before you can comment on or make changes to this bug.