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