Closed
Bug 489146
Opened 16 years ago
Closed 15 years ago
tracemonkey is disabled for Linux x64
Categories
(Core :: JavaScript Engine, enhancement, P3)
Tracking
()
RESOLVED
FIXED
mozilla1.9.3a1
People
(Reporter: tim.babych, Unassigned)
References
()
Details
(Whiteboard: NO "me too" comments please! see comment #16)
Attachments
(1 file)
479 bytes,
patch
|
gal
:
review+
|
Details | Diff | Splinter Review |
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•16 years ago
|
||
yes, it is still disabled.
Comment 2•16 years ago
|
||
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.
Assignee: nobody → gal
Severity: normal → enhancement
Priority: -- → P3
Target Milestone: --- → Firefox 3.5
Comment 3•16 years ago
|
||
I volunteer to help with x86_64 Linux testing. I routinely build from hg.
Comment 5•16 years ago
|
||
I also volunteer to help test. I have been building nightly x64 3.1/3.5 for a while.
Comment 6•16 years ago
|
||
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•16 years ago
|
||
I also have an x86-64/Linux box.
Still not fixed in the RC... were you hoping to have this working by the gold release?
Comment 9•16 years ago
|
||
no
Assignee: gal → general
Component: Build Config → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
Target Milestone: Firefox 3.5 → mozilla1.9.2a1
Version: 3.5 Branch → Trunk
Comment 10•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
it would be great: i'm monitoring this bug for the good news
Comment 13•16 years ago
|
||
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•16 years ago
|
||
(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•16 years ago
|
||
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•16 years ago
|
||
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.
Blocks: 457879
Comment 17•16 years ago
|
||
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•16 years ago
|
||
i'm ready for testing, too
Comment 19•16 years ago
|
||
I also use Linux x86_64 and the official Adobe/Java 64bit plugins without any problems.
Updated•16 years ago
|
Whiteboard: NO "me too" comments please! see comment #16
Comment 20•16 years ago
|
||
(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•16 years ago
|
||
(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•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
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).
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•16 years ago
|
||
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?
Updated•15 years ago
|
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
Attachment #400904 -
Flags: review?(gal)
Updated•15 years ago
|
Attachment #400904 -
Flags: review?(gal) → review+
Comment 28•15 years ago
|
||
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•15 years ago
|
||
(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).
(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•15 years ago
|
||
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•15 years ago
|
||
I'm surprised the CC="gcc -m64" stuff is necessary -- I thought 10.6 was 64-bit by default?
Comment 33•15 years ago
|
||
#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•15 years ago
|
||
The build instructions in comment 27 work fine on Mac OS X 10.5 on my newer MBP.
(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•15 years ago
|
||
Comment 37•15 years ago
|
||
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•15 years ago
|
||
I guess we can close this one. Thanks for everyone's patience.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 39•15 years ago
|
||
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.
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.
Updated•15 years ago
|
Target Milestone: mozilla1.9.2a1 → mozilla1.9.3a1
Comment 41•15 years ago
|
||
we're not taking this on 1.9.2
Comment 42•15 years ago
|
||
(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.
You need to log in
before you can comment on or make changes to this bug.
Description
•