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.


  1. Natanael L

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

    March 1st, 2010 at 14:33
    1. Y

      too much jagermeister…

      March 1st, 2010 at 14:47
    2. Julian

      Jäger is German and means “hunter”

      March 1st, 2010 at 14:53
  2. Christopher Blizzard

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

    March 1st, 2010 at 14:43
  3. Robert Stuart

    Jäger is German for hunter here:

    March 1st, 2010 at 15:18
  4. Klaus

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

    March 1st, 2010 at 15:43
  5. Markus Popp

    Jäger is the German word for hunter.

    March 1st, 2010 at 16:34
  6. Chris Ainsley

    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?

    March 1st, 2010 at 18:23
  7. WulfTheSaxon

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

    March 1st, 2010 at 19:29
  8. Phil

    Any rough estimates as to when it will be ready?

    March 2nd, 2010 at 02:22
  9. BWRic

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

    March 2nd, 2010 at 03:17
  10. Christopher Blizzard

    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.

    March 2nd, 2010 at 14:20
    1. Magne Andersson

      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 ;-)

      March 7th, 2010 at 04:27
    2. Magne Andersson

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

      March 7th, 2010 at 04:29
  11. mARK tWAIN

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

    March 3rd, 2010 at 08:26
  12. […] Older Article […]

    March 5th, 2010 at 13:29
  13. […] 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 […]

    March 8th, 2010 at 14:23
  14. […] 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. […]

    May 19th, 2010 at 10:12
  15. […] 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 […]

    July 1st, 2010 at 15:33
  16. 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…

    January 23rd, 2011 at 18:36
  17. jojo

    is the above still true for fire fox 4?

    May 7th, 2011 at 14:20
  18. Sarah Spicer

    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.

    May 29th, 2011 at 10:10
    1. louisremi

      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.

      May 30th, 2011 at 02:54
  19. Pablo Cuadrado

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

    June 15th, 2011 at 13:12
  20. […] 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 […]

    March 3rd, 2012 at 09:51

Comments are closed for this article.