Closed Bug 489146 Opened 16 years ago Closed 15 years ago

tracemonkey is disabled for Linux x64

Categories

(Core :: JavaScript Engine, enhancement, P3)

Product:
Core
Component:
JavaScript Engine
Platform:
x86_64
Linux
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.3a1

People

(Reporter: tim.babych, Unassigned)

References

(
URL
)

Details

(Whiteboard: NO "me too" comments please! see comment #16)

Attachments

(1 file)

enables x64 backend
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.
yes, it is still disabled.
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
I volunteer to help with x86_64 Linux testing. I routinely build from hg.
I also volunteer to help test. I have been building nightly x64 3.1/3.5 for a while.
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.
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?
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
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.
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.
it would be great: i'm monitoring this bug for the good news
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.
(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.
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.
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
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.
i'm ready for testing, too
I also use Linux x86_64 and the official Adobe/Java 64bit plugins without any problems.
Whiteboard: NO "me too" comments please! see comment #16
(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?
(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.
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.
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.
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.
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?
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)
Attachment #400904 - Flags: review?(gal) → review+
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).
(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
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.
I'm surprised the CC="gcc -m64" stuff is necessary -- I thought 10.6 was 64-bit by default?
#32: it sorta is, maybe our build system doesn't recognize whats going on without it. I observed as well that its necessary
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.
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
I guess we can close this one. Thanks for everyone's patience.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
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.
Target Milestone: mozilla1.9.2a1 → mozilla1.9.3a1
we're not taking this on 1.9.2
(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.

Attachment

General

Creator:
Created:
Updated:
Size: