improving JavaScript performance with JägerMonkey

In August 2008, Mozilla introduced TraceMonkey. The new engine, which we shipped in Firefox 3.5, heralded a new era of performance to build the next generation of web browsers and web applications. Just after the introduction of our new engine Google introduced V8 with Chrome. Apple also introduced their own engine to use in Safari, and even Opera has a new engine that they’ve introduced with their latest browser beta.

As a direct result of these new engines we’ve started to see new types of applications start to emerge. People experimenting with bringing Processing to the web, people experimenting with real-time audio manipulation, games and many other things. (For some good examples have a look at our list of Canvas demos.)

We’ve learned two things at Mozilla about how our JavaScript engine interacts with these new applications:

  1. That the approach that we’ve taken with tracing tends to interact poorly with certain styles of code. (That NES game example above, for example, tends to perform very badly in our engine – it’s essentially a giant switch statement.)
  2. That when we’re able to “stay on trace” (more on this later) TraceMonkey wins against every other engine.

Mozilla’s engine is fundamentally different than every other engine: everyone else uses what’s called a “method-based JIT”. That is, they take all incoming JS code, compile it to machine code and then execute it. Firefox uses a “tracing JIT.” We interpret all incoming JS code and record as we’re interpreting it. When we detect a hot path, we turn that into machine code and then execute that inner part. (For more background on tracing, see this post on hacks from last year.)

The downside of the tracing JIT is that we have to switch back and forth between the interpreter and the machine code whenever we reach certain conditions. When we have to jump back from machine code to the interpreter this is what we call being “knocked off trace.” The interpreter is, of course, much slower than running native machine code. And it turns out that happens a lot – more than anyone expected.

So what we’re doing in our 2nd generation engine is to combine the best elements of both approaches:

  1. We’re using some chunks of the WebKit JS engine and building a full-method JIT to execute JavaScript code. This should get us fast baseline JS performance like the other engines. And most important, it will be consistent – no more jumping on and off trace and spending a huge amount of time in interpreted code.
  2. We’ll be bolting our tracing engine into the back of that machine code to generate super-fast code for inner loops. This means that we’ll be able to still have the advantages of a tracing engine with the consistency of the method-based JIT.

This work is still in the super-early stages, to the point where it’s not even worth demoing, but we thought it would be worth posting about so people understand the basics of what’s going on.

You can find more information about this on David Mandelin‘s and David Anderson‘s weblogs as well as the project page for the the new engine.


Comments are now closed.

  1. Natanael L wrote on March 1st, 2010 at 14:33:

    I wanna know where the name comes from.
    JägerMonkey? “Jäger” sounds scandinavian to me (I’m a Swede myself).

    1. Y wrote on March 1st, 2010 at 14:47:

      too much jagermeister…

    2. Julian wrote on March 1st, 2010 at 14:53:

      Jäger is German and means “hunter”

  2. Christopher Blizzard wrote on March 1st, 2010 at 14:43:

    I’m not entirely sure, but I suspect it’s actually this:

  3. Robert Stuart wrote on March 1st, 2010 at 15:18:

    Jäger is German for hunter here:

  4. Klaus wrote on March 1st, 2010 at 15:43:

    Jäger is german and means “hunter”. Maybe hunting the faster JS engines?!?

  5. Markus Popp wrote on March 1st, 2010 at 16:34:

    Jäger is the German word for hunter.

  6. Chris Ainsley wrote on March 1st, 2010 at 18:23:

    This is excellent news.

    Two questions:

    What is the theoritical performance of the new engine versus C++ code?

    Can you comment if dynamic audio generation (as required by emulators or sound editing web-apps) is part of the draft HTML5 specification?

  7. WulfTheSaxon wrote on March 1st, 2010 at 19:29:

    Also possibly a hidden reference to Chuck Yeager (first pilot to break the sound barrier).

  8. Phil wrote on March 2nd, 2010 at 02:22:

    Any rough estimates as to when it will be ready?

  9. BWRic wrote on March 2nd, 2010 at 03:17:

    This is why I Iove open source – being able to take code from a competitor to improve your own product.

  10. Christopher Blizzard wrote on March 2nd, 2010 at 14:20:

    Yeah, well, to be clear we’re taking a pretty small piece of the WebKit engine and using it. (It’s clean code compared to the one that’s in V8.)

    And we’re still using a small bit of the old Tamarin project called Nanojit. We still collaborate heavily with Adobe on that, sharing a lot of code and work.

    So, yeah, it’s interesting to see how we’re actually collaborating with other browsers on code. The default for browsers is now open source (at least with the core engines.) Makes things easier in a lot of ways.

    1. Magne Andersson wrote on March 7th, 2010 at 04:27:

      Considering how much code from other browsers that Google Chrome contains (lots from Mozilla-projects, I’ve heard), I think it’s a fair exchange of code ;-)

    2. Magne Andersson wrote on March 7th, 2010 at 04:29:

      Oops, it wasn’t from the V8 engine. I guess it’s good anyways ;p

  11. mARK tWAIN wrote on March 3rd, 2010 at 08:26:

    That would explain why some of my sites don’t work with java script ;) noticed this in 3.6 and above.

  12. Pingback from Mozilla developer preview (Gecko 1.9.3a2) now available ✩ Mozilla Hacks – the Web developer blog on March 5th, 2010 at 13:29:

    […] Older Article […]

  13. Pingback from a quick note on JavaScript engine components ✩ Mozilla Hacks – the Web developer blog on March 8th, 2010 at 14:23:

    […] have been a bunch of posts about the JägerMonkey (JM) post that we made the other day, some of which get things subtly wrong about the pieces of technology […]

  14. Pingback from quarterly developer survey update ✩ Mozilla Hacks – the Web developer blog on May 19th, 2010 at 10:12:

    […] While there was much praise for Firefox throughout the survey responses, there were also many voices asking for performance and stability improvements. These improvements are currently under way, as you can see for example with the ongoing work on Firefox startup time and stability, and on JavaScript performance. […]

  15. Pingback from Firefox 4 beta 1 is here – what’s in it for web developers? ✩ Mozilla Hacks – the Web developer blog on July 1st, 2010 at 15:33:

    […] JavaScript engine is much faster as well, although beta 1 does not include the new JaegerMonkey work. That work is well underway and will be landing through the beta process, and is already […]

  16. Trackback from Quora on January 23rd, 2011 at 18:36:

    Is there any alternative to writing multiple “else if” statements?…

    While there are alternatives to writing if/else if/else, if you’re trying to get the best performance from your JavaScript, you’ll likely want to stick with if/else (note, I dropped the “else if” ). The reason I recommend sticking with that strateg…

  17. jojo wrote on May 7th, 2011 at 14:20:

    is the above still true for fire fox 4?

  18. Sarah Spicer wrote on May 29th, 2011 at 10:10:

    I just happened upon this article. I have had stability problems in Firefox since upgrading to 4.0. It takes longer to start-up, pages get stuck, I get script messages all the time, and facebook barely runs on it. Can you shed any light on what I can do to help this problem. The only thing I can think of is to try to find the previous Firefox build and re-install it so I go backwards to when there were not these problems.
    I would really appreciate any information that can be sent to me at in case I cannot find my way back here. Thank you to all who help.

    1. louisremi wrote on May 30th, 2011 at 02:54:

      Hi Sarah,
      you can start by saving your bookmarks and passwords using Firefox Sync and then create a brand new profile using the profile manager.

  19. Pablo Cuadrado wrote on June 15th, 2011 at 13:12:

    Hi! Is (or will be) there some performance monitor/visualization thingy like TraceVis working with the latest JagerMonkey engine?

  20. Pingback from a quick note on JavaScript engine components | Web Fada Blog on March 3rd, 2012 at 09:51:

    […] There have been a bunch of posts about the JägerMonkey (JM) post that we made the other day, some of which get things subtly wrong about the pieces of technology […]

Comments are closed for this article.