User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:13.0a1) Gecko/13.0a1 Firefox/13.0a1 Build ID: 20120218031156 Steps to reproduce: 1. Start Firefox with clean profile 2 Open URL http://www.webkit.org/perf/sunspider-0.9.1/sunspider-0.9.1/driver.html Actual results: http://hg.mozilla.org/mozilla-central/rev/d45c7d7b0079 Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:13.0a1) Gecko/20120215 Firefox/13.0a1 ID 20120215031155 237.3ms First slow Build http://hg.mozilla.org/mozilla-central/rev/46e22ce549b0 Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:13.0a1) Gecko/20120215 Firefox/13.0a1 ID 20120215083849 399.4ms
Ed, Marco, you were looking into this, right? Confirming, since our test automation saw this too.
I've bisected using inbound win64 non-pgo tinderbox builds, and get 320ms on 85f3cf72938a and 529ms on 9e93f190f64c. hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=85f3cf72938a&tochange=9e93f190f64c -> Bug 700822
> hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=85f3cf72938a&tochange=9e93f190f64c Correctly linkified: https://hg.mozilla.org/integration/mozilla-inbound/rev/9e93f190f64c Meant to add that the testing above was on Win7 x64, but this was also seen on tinderbox once inbound merged to mozilla-central (win64 talos doesn't run on inbound \o/): https://groups.google.com/d/msg/mozilla.dev.tree-management/5VxnjZSzZOw/aY8V-wbczUoJ
I'm guessing that this is because JM is generating a lot more "far jumps" on x64 than we used to, because VirtualAlloc was packing our JIT code together in memory space. I don't really remember the specifics of how far jumps were implemented on x64, but I'll check it out soon. Quick and dirty solution to restore perf is to disable VirtualAlloc randomization on the x64 builds.
What about the Quick and dirty solution?
(In reply to SpeciesX from comment #5) > What about the Quick and dirty solution? I verified that it does in fact give a big SunSpider speedup on x64 using a version too quick and dirty to land. I'll get a real patch up in a day or two.
Created attachment 606036 [details] [diff] [review] Patch Disables address randomization on x64.
Comment on attachment 606036 [details] [diff] [review] Patch [Approval Request Comment] Regression caused by (bug #): 700822 User impact if declined: 2x SunSpider regression on Win64. Suspected similar regression on other JS worksloads, but unknown. Testing completed (on m-c, etc.): Tested on try, landed to m-c. Risk to taking this patch (and alternatives if risky): Almost none--it has no effect on platforms other than Win64. On Win64, it just restores the jitcode allocation behavior to what it was before 700822.
Comment on attachment 606036 [details] [diff] [review] Patch [Triage Comment] Approved for Aurora 13 and Beta 12 - I don't see any reason to take this on m-r since it's not a shipping config.
(In reply to Alex Keybl [:akeybl] from comment #11) > Comment on attachment 606036 [details] [diff] [review] > Patch > > [Triage Comment] > Approved for Aurora 13 and Beta 12 - I don't see any reason to take this on > m-r since it's not a shipping config. Turns out the bug doesn't affect release (nor beta)--it started with 13, but I misread the report and thought it affected release. My bad.
Verified as fixed on: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0 The results from http://www.webkit.org/perf/sunspider-0.9.1/sunspider-0.9.1/driver.html averaged around 245 ms.
Verified as fixed with the STR from comment 0 on: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0 (20120605113340) The result from http://www.webkit.org/perf/sunspider-0.9.1/sunspider-0.9.1/driver.html was 258.2ms.