Feeds

back to article Mozilla orders Jäger shot for Firefox engine

Mozilla is brewing a new extension to the Firefox JavaScript engine, hoping to fix a flaw in its setup that occasionally sends the open source browser back to 2007. Dubbed JaegerMonkey, the new extension will operate alongside the much-ballyhooed TraceMonkey - an extension that debuted with Firefox 3.5 in June of last year - …

COMMENTS

This topic is closed for new posts.

Interesting confirmation of my observations

This confirms my own observations and I will be interested to see what effect this new technique has. I have some heavily compute-intensive JavaScript which I was seeing running slower in 3.5 and 3.6 with TraceMonkey turned on than in 3.1.

What is interesting to me is that the core of this code, which was absorbing more than 90% of the time, was a fairly simple pair of loops that had no recursion nor anything else fancy at all.

0
0
Thumb Down

It's so easy

Forget all that dynamic mumbo-jumbo of JITing and interpreting. Just download the stuff, compile everything to the last statement into machine code and fire it off. Delphi has demonstrated that a compiler does not need to the the sllooowwwisshh C++ clunker.

That means one can do the same for javascript. It might be a bit more difficult because variables are dynamically typed etc, but I am sure one can find good solutions for this. The whole JIT idea has been disproven by the Stanford University Network folks.

Also, if you see the same script twice, just grab into your cache and get that version you compiled yesterday.

0
3
Bronze badge

Re: It's so easy

If it were, you'd have read the article - the problem comes when *tracing* the code (which is why it's called TRACEmonkey). If you compile it whole-sale, you loose the human-readable traceability.

1
0

@jlocke

or combine the two approaches -- try googling for "slim binaries" of Oberon.

0
0
Linux

Mozilla people heard your ideas then?

@jlocke - I'm sure if your ideas are provably good then they'll adopt them.

0
0
Bronze badge

I agree

I agree with jlocke - doing the old fashioned thing of compiling to a native executable is surely going to give the best performance. And surely no script download speed can be swifter than a compiler, so what's the problem with JOT (just one time) compiling?

0
0
Silver badge

Not if the compile time

outstrips the run time. Tracing can give benefits over full compilation in specific situations.

0
0
Paris Hilton

Why re-use when you can re-invent the wheel?

Billions of dollars were invested in some great JVM and .NET virtual machines over the last 15 years. And yet, we feel compelled to throw it all out (again) and re-do our compiler technology (yet again) --- this time because we think that somehow, JavaScript is the language that will save us all.

Pathethic.

0
7
FAIL

@Bob 18

Yes, because Java and .NET are well known to be fast and entirely effective at driving events on a webpage.

7
0
Bronze badge
Thumb Down

Duh! Fail!

How does .Net technology help on most of FF's non-MS platforms? And, why would I want to bolt JS onto a JVM?

Javascript does save us all, in the specific context of a browser. Or does you want to run C# or Java in a browser? VBScript nostalgia perhaps?

Last but not least, I would rather have JS execution kept well away from any .Net/JVM I might have on my machine. You know, that outdated and bizarre concept called sandboxing that I have an irrational fondness for.

To the FF team - great work guys, keep at it.

0
0

Precompiled executables cached from trusted CDNss

Mozilla has spent a good deal of time and effort with their add-ons database all provided under a Mozilla SSL cert and with full security checks. As such, with JS libraries like jQuery, prototype and MooTools as well as commonly used helpers like swfobject or scrip.aculo.us all hosted on a variety of Content Download Networks (CDNs, ie like google's: http://code.google.com/apis/ajaxlibs/documentation/ or the MS equivalent: http://www.asp.net/ajaxlibrary/cdn.ashx).

Given the above, then why doesn't Mozilla host precompiled executables of 'approved' common javascript library 'stacks' so that when referenced, they execute fully compiled bytecode instead of parsing the whole lot through an interpreter - especially since the 'custom' code usually involves just a few URL pointers and meta information commanding the stack to show the mojo it needs to. They could work like SSL CA's are managed in the browser, so that trusted libs, like trusted CA's are automatically updated.

0
0
Silver badge

Hopefully

This will this fix the appalling, treacle like behaviour firefox demonstrates in gmail

1
0
Silver badge

More Caffeine ......

"With Mozilla's current setup, code that can't be optimized with TraceMonkey is kicked back to an aging interpreter that runs JavaScript at speeds reminiscent of the dark ages before Firefox 3.5 or Google Chrome."

It is as well to remember that in darker ages was all code alien and freely available. Now it is a plaything to monetise in Unconventional and Irregular Conservative Capitalism.

And QuITE a Colossal Mozilla Project for Military Monied Media Moguls too for the Holy Trinity of Might, Means and Message in AI Singularity HyperRadioProActive, is an Impossible Strain to Train and Enjoy with Insatiable Passions ..... ergo is IT a Labour of LOVE Extraordinarily Rendered and Delivered for You Too To Use/Experience/Driver.

"The JaegerMonkey project is only about two months old - and it's a ways from testing in a Firefox beta build - but a blog post from Mozilla programmer David Anderson says it's already providing a 30 per cent performance boost over that old interpreter on x86 machines." ..... Hmmm. Cade, what is to say that this post is not exercising and performance testing a Particularly and Peculiarly Stealthy Firefox beta build Launching the Browser into Quantum Fields of Registered Search Product Placements ...... Virtual Reality SpaceScapes/CHAOS Diaspora.

Or is that Google's Master Oracle Plan to Out Vanquish Microsoft?

0
1

@MrHorizontal

How much easier would that make life for a malware author, or a hacker. Apart from the fact that Firefox compiles on the users computer not on some domain owned by Mozilla, what then would be use of what you suggest, other than to slow down or freeze Firefox to an unusable pace.

Agree with Bob 18 entirely, scrap Java altogether, it's more hassle than it's worth.

0
0
Bronze badge

Errr... Java-_script_, Neal.

Still not the most informed of fellas, are we? Confusing Java and Javascript is nothing to be ashamed of, most people have a life that does not involve diffing the 2. Unless of course you feel you have to contribute to something you have no clue about.

And, skipping that tiny, tiny, detail, what would your clever self nominate to take JavaSCRIPT's place?

0
0
Thumb Up

@MrHorizontal

Let me rephrase your idea: Have a Compilation Proxy, run by Mozilla and other large entities like Google, which will compile JavaScript in x86 binaries *on demand* by firefox.

The CP is authenticating itself using https. This would result in about the same download times as the current arrangement and zero compilation time (after the initial compilation).

I suggested this idea for Java also. Maybe Larry will finally make a proper version of Java available....

0
0
Silver badge
FAIL

My coffee's cold

Could it be that the problem is Java, not the compiler methods?

Insanity: Doing the same thing over and over again and expecting different results. Albert Einstein.

0
0
FAIL

Err....

We're talking about JavaScript, not Java, they aren't the same thing.

Try to keep up.

2
0

@jlocke

Even with the re-interpretation, it doesn't get any better does it. Asuming (to be genorous) a 30% market share for Firefox, that's going to be 30% of the worlds bandwith eaten up at any one time, simply by Firefox checking home periodically. Some will put Firefox's market share even higher, some even less, the point is, whatever the market share Firefox actually does have, the corresponding % of bandwidth dissapears.

So maybe Firefox will become the fastest browser on the web, at the expense of the internet as a whole, who's going to buy that?

0
0
Go

@Neal 5

I am not sure what you are talking about. Firefox updates ? My suggested scheme ? The first is surely much less than the html traffic.

And the second would of course be made part of an intelligent protocol: JavaScript code like a JS function (or a sequence of that) would be post-processed before shoved on the web server and replace by an SHA hash code and additional files containing the JavaScript. The SHA could then be used by the CP to look into the cache and return the binary x86 or ARM (or any other CPU architecture) code.

Only if the cache did not contain the binary, a simple mechanism would download the JavaScript source and the CP would compile it into a binary. So only the first compilation would involve duplicate transfer of JavaScript code.

0
0
Pint

When it crashes..

.. you get a Jäger Bomb!

0
0

does this mean

that experts in the field are Jägermeisters? Or is that just their preferred tipple?

0
0
Pint

@When it crashes..

No, then you should drink one of these:

http://www.jaegermeister.de/default.aspx?#/de-de/mixing/

Well, actually I would not suggest it. It tastes a bit strange.

Better go for the beer.

0
0

@jlocke

Still no improvement. 30% market share latching onto a web server, Sure anyone out there other than perhaps Google can handle that load?

Even if you went cloudy with it, what sort of a data centre architecture would be able to handle it?, and for what, so Firefox can save maybe 3 nano seconds on compilation. When in your world, does expense bear no reality to saving.? Let me guess, you work for RBS, or HBOS, possibly even Lloyds, that's the only place I can think of, where those sort of economies feature.

Best place for compilation is in browser, even better, scrapping Java altogether.

0
0
Go

@Neal 5

You could run that Compilation Proxy also in your intranet. It would make the browser lighter, as the compiler is not pushed to each and every desktop. Secondly, this would ensure the confidentiality of your inhouse JS apps.

And, performance IS a Big Issue. Applications like Google Docs need all the JS horsepower they can get and more and more other applications also.

You can do really nice things with JS, and I think Google Apps is just a glimpse of the future. And certainly, the faster JS becomes, the more things will be possible.

Please don't confuse it with Java; "JavaScript" is technologically something totally different. Even though that it appears to be a slower technology, it actually delivers on the promises that Java Applets made.

0
0
This topic is closed for new posts.