When we turned on method jit for chrome, we didn't really see that much of a gain in performance, if any. But we are using more memory in the parent process because of it. This patch turns off methodjit for chrome. You will still see some parent process mjit usage in about:memory because some webpage (content) are loaded in the parent process.
Attachment #556061 - Flags: review?(mbrubeck)
Comment on attachment 556061 [details] [diff] [review] patch Review of attachment 556061 [details] [diff] [review]: ----------------------------------------------------------------- Don't check in the mozconfig.
Attachment #556061 - Flags: review?(mbrubeck) → review+
removed the mozconfig and actually set the pref to false http://hg.mozilla.org/integration/mozilla-inbound/rev/60594ddf3d9e
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 9
Comment on attachment 556061 [details] [diff] [review] patch To help reduce memory usage
I second the aurora/beta nominations. The method JIT uses a lot of memory. And it should be very low-risk, since it was off previously.
Comment on attachment 556061 [details] [diff] [review] patch Approved for releases/mozilla-aurora and releases/mozilla-beta. Please land asap.
status-firefox7: --- → fixed
status-firefox8: --- → fixed
status-firefox9: --- → fixed
Target Milestone: Firefox 9 → Firefox 7
Is there a bug on file for doing this on desktop firefox?
(In reply to Kyle Huey [:khuey] (firstname.lastname@example.org) from comment #8) > Is there a bug on file for doing this on desktop firefox? Not that I am aware of, but desktop might have different behavior/goals. It's a tradeoff and on mobile we traded for memory.
I'm worried this change will make computationally intensive add-ons much slower. Why was this solution chosen as opposed to, say, tweaking the method jit heuristics to kick in less often?
Are people running computationally intensive addons on mobile? Also, there's still the tracer, right?
(In reply to Kyle Huey [:khuey] (email@example.com) from comment #11) > Are people running computationally intensive addons on mobile? It's possible I guess > Also, there's still the tracer, right? Yes, the tracer is still enabled
The tracer is disabled by default. Does disabling the method jit actually enable the tracer? How long until the tracer is ripped out?
qa- as no QA fix verification is needed
I think the mjit's problem here is in its technique for discarding jitcode. Stock JM occasionally tries to discard jitcode during GC, but can only do so if the jitcode's compartment does not have active frames on the stack. I noticed when fixing bug 688292 that when we GC there is almost always chrome code on the stack (at least on some workloads), which will cause mjit code to be discarded even slower. In compartments with TI enabled (not chrome) this is different, and all jitcode is discarded on every GC even in compartments with frames on the stack. I tried to do this for stock JM too in bug 685358, but ran into problems with JM+TM integration (weird corruption problems). By removing the tracer or decoupling it from JM, that bug could reland.
You need to log in before you can comment on or make changes to this bug.