Last Comment Bug 489146 - tracemonkey is disabled for Linux x64
: tracemonkey is disabled for Linux x64
Status: RESOLVED FIXED
NO "me too" comments please! see comm...
:
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86_64 Linux
: P3 enhancement with 21 votes (vote)
: mozilla1.9.3a1
Assigned To: general
:
Mentors:
http://www.kairo.at/demo/mandelbrot-web/
: 489136 597160 (view as bug list)
Depends on: 457879 512409
Blocks: 515310
  Show dependency treegraph
 
Reported: 2009-04-20 04:04 PDT by Tim Babych
Modified: 2010-09-16 18:23 PDT (History)
50 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
enables x64 backend (479 bytes, patch)
2009-09-15 16:37 PDT, David Anderson [:dvander]
gal: review+
Details | Diff | Splinter Review

Description Tim Babych 2009-04-20 04:04:07 PDT
When testing KaiRo's mandelbrot demo I do not see any improvements in rendering speed whether jit.content in true or not. 6 seconds just like Firefox 3 does.

System:
Linux denmark 2.6.27-14-generic #1 SMP Wed Apr 15 19:29:46 UTC 2009 x86_64 GNU/Linux

Browser is nightly build of Firefox 3.5 x64

Then tried 686 build on the same system and got 1.5 seconds.

When disabled JIT on that one got 7 seconds.

x64 jit
6.616 seconds

i686 jit
1.219 seconds

x64 no jit
7.613 seconds

Is JIT still disabled on x64 Linux?

Looked at bug 451602 and bug 237202 and havent found anything on it, so filing this one.
Comment 1 Robert Sayre 2009-04-20 08:06:58 PDT
yes, it is still disabled.
Comment 2 Andreas Gal :gal 2009-04-20 08:13:33 PDT
We can use this bug to track merging in the new amd64 backend. If we can gather 2-3 volunteer testers with amd64 linux installations that would be great. I will probably do most of the testing on amd64 macosx shell only since thats my main development box.

Not a blocker.
Comment 3 Joseph Felps 2009-04-21 13:27:14 PDT
I volunteer to help with x86_64 Linux testing.  I routinely build from hg.
Comment 4 Sylvain Pasche 2009-04-25 19:52:59 PDT
*** Bug 489136 has been marked as a duplicate of this bug. ***
Comment 5 Nephyrin Zey 2009-05-13 14:44:42 PDT
I also volunteer to help test. I have been building nightly x64 3.1/3.5 for a while.
Comment 6 Andreas Gal :gal 2009-05-13 14:49:27 PDT
We are doing pretty well with blockers. As soon 3.5 freezes I will make this my pet project. We will also have the original author of the amd64 backend for tracemonkey in town for the summer. This is definitively wanted, it just got pushed back a bit by higher priority stuff.
Comment 7 Nicholas Nethercote [:njn] 2009-05-13 18:48:56 PDT
I also have an x86-64/Linux box.
Comment 8 Dannii 2009-06-22 05:57:58 PDT
Still not fixed in the RC... were you hoping to have this working by the gold release?
Comment 9 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2009-06-22 06:17:59 PDT
no
Comment 10 Dannii 2009-06-22 06:21:39 PDT
That's very unfortunate... I'll have to go back to 32bit builds then. Haven't done that since flash was a problem.

Anyways, I'm happy to test anything.
Comment 11 Andreas Gal :gal 2009-06-22 07:12:26 PDT
Wasn't a goal for 3.5, but since this is pretty orthogonal to the 32-bit code, I think there is a realistic chance we can add this for 3.5.x. We have a working 64-bit backend contributed by Adobe. All we need is a little integration work.
Comment 12 federico fissore 2009-06-23 08:47:34 PDT
it would be great: i'm monitoring this bug for the good news
Comment 13 Ryan Hayle 2009-06-30 10:41:48 PDT
It was a big mistake not to block on this issue when you are trying to advertise the speed improvements of 3.5 over 3.0, which many users will not even see without TraceMonkey.  Is there a branch with the 64-bit backend available yet?  I'll help with testing as soon as it is.
Comment 14 Nicholas Nethercote [:njn] 2009-06-30 16:48:41 PDT
(In reply to comment #13)
> It was a big mistake not to block on this issue when you are trying to
> advertise the speed improvements of 3.5 over 3.0, which many users will not
> even see without TraceMonkey.

It's my understanding that most users will end up with a 32-bit version of Firefox, even if they have a 64-bit machine.  Reason being that 64-bit plug-in support is still not very good, so Mozilla mostly ships 32-bit builds.
Comment 15 Denis Falqueto 2009-07-02 09:41:32 PDT
Plugins are not a concern for x86_64 anymore. There are native plugins for Java by Sun and Flash by Adobe, so I am very reluctant to go back to Firefox 32 bits, because I'll need lots of 32 bits libraries too. My system is pure x86_64 (ArchLinux btw) and it's working just fine. If there is any need of testing, I can help it too.
Comment 16 Arpad Borsos [:Swatinem] 2009-07-02 10:06:47 PDT
There is an updated x64 Backend for nanojit in the "tamarin-redux" branch that will be merged "once the devs have time" which I hope shouldn't take that long now that 1.9.1 is out of the door.
Comment 17 Frederic Bezies 2009-07-02 10:15:45 PDT
I can be a tester if you need one. Just tell me what to do, I really want to test a 64 bits version of tracemonkey.
Comment 18 federico fissore 2009-07-02 11:53:48 PDT
i'm ready for testing, too
Comment 19 archlinux 2009-07-02 13:30:56 PDT
I also use Linux x86_64 and the official Adobe/Java 64bit plugins without any problems.
Comment 20 koralik 2009-07-04 15:40:34 PDT
(In reply to comment #16)
> There is an updated x64 Backend for nanojit in the "tamarin-redux" branch that
> will be merged "once the devs have time" which I hope shouldn't take that long
> now that 1.9.1 is out of the door.

Is there a way to merge source of this backend with mozilla-central or tracemonkey branch, which can produce a testing build?
Comment 21 Graydon Hoare :graydon 2009-07-06 11:19:53 PDT
(In reply to comment #20)
> (In reply to comment #16)
> > There is an updated x64 Backend for nanojit in the "tamarin-redux" branch that
> > will be merged "once the devs have time" which I hope shouldn't take that long
> > now that 1.9.1 is out of the door.
> 
> Is there a way to merge source of this backend with mozilla-central or
> tracemonkey branch, which can produce a testing build?

Not an easy way, no. That's what is meant by "once the devs have time". It's a several-day task for someone familiar with both x64 and the nanojit assembler interface, to merge to the point of building and even beginning to work in a 64bit firefox build, and currently this is lower priority than a lot of other matters taking our time (note: it's rated P3 importance, enhancement, non-blocking status). It will be gotten-to eventually. If you were to copy the native x64 backend files from one repository to another, without such merging work, you'd almost certainly get a tree that doesn't build.

Of course you're welcome to have a go at composing such a patch yourself! All repositories involved are public. It is slightly delicate work, but we'd all be pleased to get more volunteer help on nanojit.
Comment 22 Sandeep 2009-07-08 11:58:52 PDT
http://github.com/sandys/tracemonkey-64bit/tree/master

well.. having way too much time (with no work to be had) these past few days - I hacked together a buildable 64 bit nanojit. This is my first time even looking at mozilla code, so be kind to me ;)

Firstly, the code builds with "-DFEATURE_NANOJIT -DJS_TRACER" and "NANOJIT_AMD64/NANOJIT_64BIT". also "file ./js" returns 
./js: ELF 64-bit LSB executable, x86-64, version 1 (SYSV)


I had to merge code by hand from tamarin-redux, so I have a few ugly #DEFINE's in the configure file. I also pulled the "memory" directory from mozilla to make it self contained.
In all the source code, at every point that I made changes by hand, I have prepended a //sss comment, so that it is easy to backtrack.

What doesnt work: 'js -j'. I get an error "Assertion failed: operandCount[v]==1 (./nanojit/LIR.cpp:2023)". So going to go hunt around for that.

Without the "-j" option, the v8 benchmark suite goes through.

for anyone else also beginning hacking on this, I suggest reading up on "https://developer.mozilla.org/En/Nanojit":that is a wonderfully written howto.
Comment 23 Sandeep 2009-07-12 12:38:43 PDT
hmm.. js -j partially goes through (my primary testcase being the crypto-sha1 test). Stuck at the "asm_loop" function which is NOT implemented for AMD64.
Comment 24 Andreas Gal :gal 2009-07-12 14:11:17 PDT
Yeah, asm_loop is only used in TM, not in adobe's embedding. This is the reason that we couldn't simply land tamarin's backend. I would prefer to restructure our code generation to avoid asm_loop instead of implementing it, but you might also try duplicating what the other backends do. sparc is probably a close match due to the large register count (closer in this regard than x86-32).
Comment 25 David Anderson [:dvander] 2009-07-12 15:21:17 PDT
Well, there are other reasons too... the promote/demote filter has to change. Even just dropping the x64 backend in and implementing asm_loop, will result in difficult bugs.
Comment 26 Andreas Gal :gal 2009-07-12 15:39:16 PDT
Yeah, same approach here. I would prefer getting rid of the filter all together instead of trying to hack the LIR representation. David, on a related note, I wonder how the sparc backend deals with the quad/float issue? Or is the sparc backend 32-bit?
Comment 27 David Anderson [:dvander] 2009-09-15 16:37:16 PDT
Created attachment 400904 [details] [diff] [review]
enables x64 backend

Over the past two weeks I have landed most patches that make the x64 JIT working with TM. The known remaining issue are small and I am committed to fixing them.  

The JIT passes trace-tests and jstests on OS X 10.6 and Linux. Mochitests failed about 40 tests with the JIT - I fixed a bunch of serious bugs, and reran it. It failed about 26 tests. Then I realized the second run was without the JIT. But whatever, there is work to do there either way.

Getting the shell to build on OS X is a little annoying, I did something like:

AR=ar CC="gcc -m64" CXX="g++ -m64" path/to/configure --target=x86_64-apple-darwin10.0.0

The attached patch is the minimal configure changes needed to let users start testing this out. I'll let Andreas (or someone else) decide whether it should land on TM now or later. I can't guarantee that everything is working flawlessly, but it's stable enough to start using and finding whatever bugs, if any, remain.

For anyone hacking on the engine I've also written a short wiki writeup:

https://developer.mozilla.org/En/SpiderMonkey/Internals/64-bit_Compatibility
Comment 28 Andreas Gal :gal 2009-09-15 16:51:03 PDT
r=me. Historic experience shows that backends decay if we don't use them and test them right away. Lets switch it on right now. Rel eng already add a 64-bit linux builder to our waterfall despite our belated request, so at least we have some coverage that way, and some of us can switch to testing on 64-bit shell which will give us some additional confidence until better testing is in place (I will start using it today).
Comment 29 Nicholas Nethercote [:njn] 2009-09-15 17:48:58 PDT
(In reply to comment #27)
> 
> Getting the shell to build on OS X is a little annoying, I did something like:
> 
> AR=ar CC="gcc -m64" CXX="g++ -m64" path/to/configure
> --target=x86_64-apple-darwin10.0.0

This is Mac OS 10.5 or 10.6?

I've been doing something similar to get 32-bit builds on my 64-bit Linux box.

As for turning this on, I agree with Andreas -- the sooner the better!  Esp. as
I have back-end work I want to get on with (eg. bug 515310).
Comment 30 David Anderson [:dvander] 2009-09-15 18:38:25 PDT
(In reply to comment #29)
> This is Mac OS 10.5 or 10.6?

10.6 - my 10.5 MBP is old and doesn't have 64-bit support so I haven't tested on that yet.

http://hg.mozilla.org/tracemonkey/rev/b427d529e897
Comment 31 Andreas Gal :gal 2009-09-15 18:45:41 PDT
I think there is 64-bit user mode support for all reasonably recent macosx versions and the shell should build fine on 10.5 too.
Comment 32 Nicholas Nethercote [:njn] 2009-09-15 19:19:37 PDT
I'm surprised the CC="gcc -m64" stuff is necessary -- I thought 10.6 was 64-bit by default?
Comment 33 Andreas Gal :gal 2009-09-15 19:21:53 PDT
#32: it sorta is, maybe our build system doesn't recognize whats going on without it. I observed as well that its necessary
Comment 34 Jesse Ruderman 2009-09-15 19:26:29 PDT
The build instructions in comment 27 work fine on Mac OS X 10.5 on my newer MBP.
Comment 35 David Anderson [:dvander] 2009-09-15 19:32:56 PDT
(In reply to comment #32)
> I'm surprised the CC="gcc -m64" stuff is necessary -- I thought 10.6 was 64-bit
> by default?

If you can get something simpler please let me know. I think there is some conflict where the target is 32-bit by default, and when setting an x86_64 target it stops finding gcc properly.
Comment 36 Blake Kaplan (:mrbkap) 2009-09-16 17:46:13 PDT
http://hg.mozilla.org/mozilla-central/rev/b427d529e897
Comment 37 adrian 2009-10-17 14:56:08 PDT
I have tested tracemonkey in 64-bit and it seems to be working fine.  It runs much faster than the stable firefox-3.5 that comes with ubuntu since stable still doesn't have tracemonkey.  Sunspider ran 3x faster.

I'm using firefox-3.7 ubuntu nightly-PPA and it makes things very easy:  https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
Comment 38 Andreas Gal :gal 2009-10-17 15:01:02 PDT
I guess we can close this one. Thanks for everyone's patience.
Comment 39 Mike Hommey [:glandium] 2010-02-26 03:35:10 PST
Is there a reason this has not landed on 1.9.2 (cf. target of this bug set to 1.9.2a1) ?

http://hg.mozilla.org/mozilla-central/rev/b427d529e897
and the configure.in part of http://hg.mozilla.org/mozilla-central/rev/f7106b6e9e3d (which was left off http://hg.mozilla.org/releases/mozilla-1.9.2/rev/fe79e28960c2) would be required.
Comment 40 David Anderson [:dvander] 2010-02-26 09:36:07 PST
It hasn't landed because the branches diverged a while ago. At this point it's not really clear if you can just flip it on in 1.9.2 and have it work. The target milestone is probably set wrong.
Comment 41 Robert Sayre 2010-02-26 09:46:27 PST
we're not taking this on 1.9.2
Comment 42 Mike Hommey [:glandium] 2010-02-26 23:45:45 PST
(In reply to comment #40)
> It hasn't landed because the branches diverged a while ago. At this point it's
> not really clear if you can just flip it on in 1.9.2 and have it work.

FWIW, 1.9.2 with the patches said in comment 39 passes the xpcshell test suite, and the trace-tests.
Comment 43 Makoto Kato [:m_kato] 2010-09-16 18:23:04 PDT
*** Bug 597160 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.