12 ms·

Firefox Nightly Gets New Baseline JIT Compiler

248 points by barkingcat 14y ago

codesuela 14y ago
If someone could answer me this it would be much appreciated: The blogpost describes the current flow of code as such: Interpreter -> JaegerMonkey -> IonMonkey Is process repeated every time I open a website or do browsers cache the generated bytecode? What about popular libraries? Will jQuery get JITed differently for every website that has it?
- kannanvijayan 14y ago
  There will be separate jitcode generated for each page. It's hard to share this kind of code because during generation we often bake-in immediate pointers to various things (like global objects, etc.) into the generated jitcode. The jitcode itself isn't that big of a memory issue, though. The collected type info is more heavyweight, but that's really hard to share across different pages. There are security concerns, concurrency concerns, and just complexity.
  - alcuadrado 14y ago
    And do you cache jitcode of the same page between different visits?
    - evilpie 14y ago
      No. We however had several ideas over the years to cache bytecode together with the JavaScript code. But that never really went anywhere. Caching JIT-code is difficult, because addresses (like jumps) change unless you malloc at the exact same location or manually fix up everything.
      - alcuadrado 14y ago
        I see. I was thinking in something more bytecode-like, didn't knew that jitcode has direct adressess in it.
      - pedroo 14y ago
        How much worse peformance-wise would generating PIC be to address this?
      - derefr 14y ago
        It sounds like you need two separate JITcode phases: first, generate Position-Independent JITcode (and cache that); then for each script that requires it, load it and "link" it.
    - kannanvijayan 14y ago
      If a page goes into the back/forward cache, then its js code generally gets kept around. But we don't persistently store jitcode for a page, and I don't know of any JS engine that does.
  - varikin 14y ago
    Would the same library generate the same jitcode on different websites? Does how the library is used account for this. At a high level, if I never used jQuery animation code on my site, but another site does, with the same jQuery version, would the jitcode for my site have removed the unnecessary animation stuff?
    - bzbarsky 14y ago
      > Would the same library generate the same jitcode on different websites? No. The jitcode is specialized based on actual observed types, so depending on how you call the methods you get different jitcode.
  - yan 14y ago
    Also, the generated JIT code isn't static and does not simply map source to native like in statically compiled languages. A lot of JS JITs, including Firefox'es, dynamically rewrite the emitted code as it executes to add support for newly-seen types. So not only will the code be different environment to environment, it will also be different within the same script execution.
- Siecje 14y ago
  Also different sites use different versions of jQuery
- nnethercote 14y ago
  More sharing would be great for memory consumption, but it's really hard. See https://bugzilla.mozilla.org/show_bug.cgi?id=846173 https://bugzilla.mozilla.org/show_bug.cgi?id=846173 for an interesting example.
happy_dino 14y ago
... which finally adds support for a common bytecode format, usable as a compilation target for various languages. Oh wait, that would actually be useful. Better just design yet-another JIT compiler to speed up that language design train wreck that is Java Script. </s>
- pjscott 14y ago
  Wrong thread; I think you meant to post a happy comment in one of the threads about asm.js, which actually could be a halfway decent common bytecode format. (It also happens to be valid JavaScript, and an ugly hack, but oh well.)
  - happy_dino 14y ago
    I had high hope, but no, it isn't. It would only let you build your own asm.js-based VM on top of the existing JavaScript-like VM which could implement some bytecode format and interpret it. I have seen something like that already. Let me tell you, you don't want to download 20 MB for some simple web-based Tetris-clone. asm.js is useless for pretty much any modern language which relies on garbage collection. I want less indirections, not more.
    - pcwalton 14y ago
      > I have seen something like that already. Let me tell you, you don't want to download 20 MB for some simple web Tetris-clone. http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling... > asm.js is useless for pretty much any modern language which relies on garbage collection. That is being worked on with the Binary Data spec: http://asmjs.org/faq.html http://asmjs.org/faq.html
      - happy_dino 14y ago
        Again, these are C/C++ use-cases. That's exactly what asm.js was made for. Apart from the potential of making some of Mozilla's insane ideas like implementing a PDF reader in JavaScript easier/faster, it's applicability is pretty much limited. No one out there who is waiting for a sane language for the web will rejoice that he can now use C/C++ instead of JavaScript. > That is being worked on with the Binary Data spec: http://asmjs.org/faq.html http://asmjs.org/faq.html I'll believe it when I see it working. Most likely they will still find a way to make it next to useless, forcing people to keep writing/targeting JavaScript.
corresation 14y ago
While the great sunspider battles will be great for the future, practically does this really matter? Does it really have any impact at all for an average user, where, I suspect, the up-front costs of JIT never actually pay themselves off. This isn't intended to be Luddism, and these improvements will benefit future apps, but so much is made about JavaScript performance (see the hoopla about JIT being disabled for embedded browsers on iOS), yet I seriously doubt it makes an ounce of difference in the real world, where the overwhelming majority of the performance limitations exist in the DOM.
- leeoniya 14y ago
  when it comes to complex web apps, it makes a huge difference. big data is coming to browsers in the form of massive typed Arrays from canvas and maybe soon, audio and video. We're talking about hotspots that get executed 10M+ times. These aren't your grandma's onclick handlers.
  - corresation 14y ago
    when it comes to complex web apps, it makes a huge difference. Such as what? Give some examples. Further -- as a developer -- I cannot fathom "big data coming to browsers". This is racing tires on street cars: Theoretically useful, but of absolutely zero relevance for the overwhelming majority of users. Never has there been an actually practical benchmark of javascript engines and legitimate, real-world websites. Instead it's all nonsense like Sunspider. And don't misunderstand -- this actually can be a net negative for users because what benefits a 10M iteration loop is of negative consequence to an occasionally run event handler.
    - leeoniya 14y ago
      i'm doing interactive image analysis in canvas. i have pixel iteration/algo loops that easily hit 10M. my canvases are typically 1550x2006. mozilla also demoed js decoding H.264 video in realtime, the utility of which is of course questionable... the point is, though, that typed arrays are already a reality, and they are enormous. you can argue about how good an idea that was, but now that they're here, JITs are absolutely necessary.
simonsarris 14y ago
MAJOR EDIT: The first tests I accidentally ran against aurora (22a) and not the nightly (23a). Running against the nightly, the numbers are much closer, though sometimes better on either 21 or 23a for some simple things. But running the typed array/pixel manipulation test, 23a seems twice as fast as the beta! http://i.imgur.com/x2otAI1.png http://i.imgur.com/x2otAI1.png Please feel free to confirm using http://jsperf.com/canvas-pixel-manipulation/6 http://jsperf.com/canvas-pixel-manipulation/6 Original post below, with erroneous benches removed: ~~~ Hmm, I have a lot of HTML canvas-based performance tests, so I plucked two of them to give a small comparison a go. Comparing the results of these simple exercises doesn't seem too promising. The first test I used was a simple one that merely sets every canvas propery (some can be time consuming): http://jsperf.com/can-attribs http://jsperf.com/can-attribs And the second one tests different ways of filling single pixels: http://jsperf.com/filling-pixels http://jsperf.com/filling-pixels From a practical standpoint canvas performance matters very much to me, but my tests probably aren't the best metric. Are there better tests that could be used to see the difference between the old and new compilers here? edit: on a test comparing typed arrays to plain, performance seemed nearly (merely?) identical: http://jsperf.com/canvas-pixel-manipulation/6 http://jsperf.com/canvas-pixel-manipulation/6
- leeoniya 14y ago
  i also have a lot of canvas-heavy code and use typed arrays pretty extensively. i think that mozilla's canvas implementation is actually the bottleneck here, not the JS. chrome's canvas proves to be much faster, though.
  - leeoniya 14y ago
    i reported the issue about a year ago, FYI. https://bugzilla.mozilla.org/show_bug.cgi?id=746773 https://bugzilla.mozilla.org/show_bug.cgi?id=746773
    - bzbarsky 14y ago
      That issue is basically fixed in most sane code, actually; I just resolved it as such. For example, on http://jsperf.com/pixel-pre-rendering/5 http://jsperf.com/pixel-pre-rendering/5 I see identical numbers for the two versions of the test.
VeejayRampay 14y ago
Damn this browser business is getting crazy these days. I wonder if we'll look at how the browser performs in say 5 years from now with the sense that 2013 was basically the dark ages. Exciting times...
- ConstantineXVI 14y ago
  Dark Ages would imply that progress was set back significantly by some catastrophic event (ie: the fall of Netscape). Renaissance would be a more apt term, given the rapid advances we're going through.
  - Teckla 14y ago
    Dark Ages would imply that progress was set back significantly by some catastrophic event (ie: the fall of Netscape). Some of us would argue that JavaScript itself was that catastrophic event. No, really -- I'm not trolling. It's no longer reasonable for people to deny that JavaScript doesn't lend itself well to optimizing run-time performance. These Herculean efforts are impressive, but perhaps it's time to fix the language, even if that breaks backwards compatibility.
    - DigitalJack 14y ago
      I've pretty much ignored javascript until this week. What exactly is wrong with it? Perhaps that is too broad. Can you give an example of something in javascript that impedes runtime performance optimization?
    - aroman 14y ago
      They're working on it; it's called ES6. But in terms of your claim that "It's no longer reasonable for people to deny that JavaScript doesn't lend itself well to optimizing run-time performance", I'm not sure what to say to that. JavaScript code is some of the fastest interpreted code around, and projects like asm.js take that even farther. It's a phenomenally beautiful and expressive language once you get around the fact that it has some minor warts. I might have agreed with you 10 years ago, but I don't think there claim that JS simply doesn't lend itself to being performant is true at all -- all the evidence I see, both as a web JavaScript and Node.js developer, and following the recent relative news, has pointed me to quite the opposite: javascript is doing great right now.
antonios 14y ago
The amount of innovation coming from Mozilla has been staggering the last year. IonMonkey, asm.js, impressive memory usage improvements (Firefox is now by far the least memory hungry browser among the modern ones), new baseline jit...Rock on, Mozilla.
- Offler 14y ago
  And Rust, linked to that Servo seems very interesting.
- nnethercote 14y ago
  > impressive memory usage improvements (Firefox is now by far the least memory hungry browser among the modern ones) What evidence do you base this on -- your own experience, or that of others, or measurements such as those done by Tom's Hardware, or something else? I'm not disputing your claim, I'd just like to know :)
  - haksan 14y ago
    http://lifehacker.com/5976082/browser-speed-tests-chrome-24-firefox-18-internet-explorer-10-and-opera-1212 http://lifehacker.com/5976082/browser-speed-tests-chrome-24-... http://www.zdnet.com/time-to-take-another-look-at-firefox-7000009692/ http://www.zdnet.com/time-to-take-another-look-at-firefox-70... http://www.tomshardware.com/reviews/chrome-17-firefox-10-ubuntu,3129-14.html http://www.tomshardware.com/reviews/chrome-17-firefox-10-ubu... googling is not rocket science. and these three links are only the newest ones, there are more from 2011.
    - antonios 14y ago
      There's also Mozilla's own "Are we slim yet?" interface to track their progress in memory usage. https://areweslimyet.com/ https://areweslimyet.com/ You can even see the bugs that lead to memory regressions there.
      - nnethercote 14y ago
sergiosgc 14y ago
How feasible would it be to have webservers compile javascript and serve it to the browser already preprocessed (as far as possible)? The same URL could be used, but a different mime type acceptance signaled by the browser using the Accepts header. The webservers, instead of returning text/javascript would return application/javascript+moz22. Then, most of this race towards hotspot optimization would be less important.
- pestaa 14y ago
  I do not trust 99 servers out of 100 including not only those I intend to communicate with but others sitting in the middle of my connection, to deliver the same binary my browser would render in a few milliseconds. The web is a wild place, let's not increase our attack surface.
crucio 14y ago
is there a way to signal to the browser that I'd like all of my JavaScript to be compiled as best as possible and that I don't mind my users waiting while this happens? Could this be useful for complex games where start-up speed may not be deemed as important as runtime performance?
- shardling 14y ago
  In a sense that's what asm.js is. Obviously not quite what you're asking for, though.
- jomohke 14y ago
  If you compiled immediately you would probably find that your games performed much worse, because the compiler would have very little information about the functions and the kind of arguments that will be passed to them. Once a function has run many times, the compiler can use the gathered statistics (such as knowing that the arguments were always floats) to produce better optimised machine code (such as using float-specific ops, and eliminating code paths that expect arguments other than floats). This is a common tradeoff for all JITs; Should I wait longer to produce better code, or compile sooner to run the faster code earlier? You can play with this number in most Java JVMs (OpenJDK or Sun/Oracle) using the argument "-XX:CompileThreshold". This sets how many times a function should run before it is compiled. It defaults to about 1500 for a client VM and 10000 for a server VM. As mentioned in a sibling comment, asm.js is a partial alternative to this tradeoff, as your asm.js code specifies all data types ahead of time, and hence they can be compiled up-front fairly well.
ritonlajoie 14y ago
I'm not a javascript nor browser pro but I wonder why the compilation is done client side. Cant's the servers do it and send the jit code to the client instead?
- sjwright 14y ago
  Too many combinations of operating system, cpu, browser, browser version -- the server would need to have a huge number of versions built and cached. And then you need to ensure your server continually has support for all the latest browsers. But even that pales in comparison to the biggest reason, which is security. In order to run fast, the compiled version needs to be "trusted" to do the right thing; by allowing the server to send pre-compiled code, you're opening up a huge number of attack vectors.
tambourine_man 14y ago
Also, to remark on recent happenings… given the recent flurry of news surrounding asm.js and OdinMonkey, there have been concerns raised (by important voices) about high-level JavaScript becoming a lesser citizen of the optimization landscape. I hope that in some small way, this landing and ongoing work will serve as a convincing reminder that the JS team cares and will continue to care about making high-level, highly-dynamic JavaScript as fast as we can. Great answer.

248 points by barkingcat 14y ago

If someone could answer me this it would be much appreciated: The blogpost describes the current flow of code as such: Interpreter -> JaegerMonkey -> IonMonkey Is process repeated every time I open a website or do browsers cache the generated bytecode? What about popular libraries? Will jQuery get JITed differently for every website that has it?

kannanvijayan 14y ago
There will be separate jitcode generated for each page. It's hard to share this kind of code because during generation we often bake-in immediate pointers to various things (like global objects, etc.) into the generated jitcode. The jitcode itself isn't that big of a memory issue, though. The collected type info is more heavyweight, but that's really hard to share across different pages. There are security concerns, concurrency concerns, and just complexity.
- alcuadrado 14y ago
  And do you cache jitcode of the same page between different visits?
  - evilpie 14y ago
    No. We however had several ideas over the years to cache bytecode together with the JavaScript code. But that never really went anywhere. Caching JIT-code is difficult, because addresses (like jumps) change unless you malloc at the exact same location or manually fix up everything.
    - alcuadrado 14y ago
      I see. I was thinking in something more bytecode-like, didn't knew that jitcode has direct adressess in it.
    - pedroo 14y ago
      How much worse peformance-wise would generating PIC be to address this?
    - derefr 14y ago
      It sounds like you need two separate JITcode phases: first, generate Position-Independent JITcode (and cache that); then for each script that requires it, load it and "link" it.
  - kannanvijayan 14y ago
    If a page goes into the back/forward cache, then its js code generally gets kept around. But we don't persistently store jitcode for a page, and I don't know of any JS engine that does.
- varikin 14y ago
  Would the same library generate the same jitcode on different websites? Does how the library is used account for this. At a high level, if I never used jQuery animation code on my site, but another site does, with the same jQuery version, would the jitcode for my site have removed the unnecessary animation stuff?
  - bzbarsky 14y ago
    > Would the same library generate the same jitcode on different websites? No. The jitcode is specialized based on actual observed types, so depending on how you call the methods you get different jitcode.
- yan 14y ago
  Also, the generated JIT code isn't static and does not simply map source to native like in statically compiled languages. A lot of JS JITs, including Firefox'es, dynamically rewrite the emitted code as it executes to add support for newly-seen types. So not only will the code be different environment to environment, it will also be different within the same script execution.
Siecje 14y ago
Also different sites use different versions of jQuery
nnethercote 14y ago
More sharing would be great for memory consumption, but it's really hard. See https://bugzilla.mozilla.org/show_bug.cgi?id=846173 https://bugzilla.mozilla.org/show_bug.cgi?id=846173 for an interesting example.

happy_dino 14y ago

... which finally adds support for a common bytecode format, usable as a compilation target for various languages. Oh wait, that would actually be useful. Better just design yet-another JIT compiler to speed up that language design train wreck that is Java Script. </s>

pjscott 14y ago
Wrong thread; I think you meant to post a happy comment in one of the threads about asm.js, which actually could be a halfway decent common bytecode format. (It also happens to be valid JavaScript, and an ugly hack, but oh well.)
- happy_dino 14y ago
  I had high hope, but no, it isn't. It would only let you build your own asm.js-based VM on top of the existing JavaScript-like VM which could implement some bytecode format and interpret it. I have seen something like that already. Let me tell you, you don't want to download 20 MB for some simple web-based Tetris-clone. asm.js is useless for pretty much any modern language which relies on garbage collection. I want less indirections, not more.
  - pcwalton 14y ago
    > I have seen something like that already. Let me tell you, you don't want to download 20 MB for some simple web Tetris-clone. http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling... > asm.js is useless for pretty much any modern language which relies on garbage collection. That is being worked on with the Binary Data spec: http://asmjs.org/faq.html http://asmjs.org/faq.html
    - happy_dino 14y ago
      Again, these are C/C++ use-cases. That's exactly what asm.js was made for. Apart from the potential of making some of Mozilla's insane ideas like implementing a PDF reader in JavaScript easier/faster, it's applicability is pretty much limited. No one out there who is waiting for a sane language for the web will rejoice that he can now use C/C++ instead of JavaScript. > That is being worked on with the Binary Data spec: http://asmjs.org/faq.html http://asmjs.org/faq.html I'll believe it when I see it working. Most likely they will still find a way to make it next to useless, forcing people to keep writing/targeting JavaScript.

corresation 14y ago

While the great sunspider battles will be great for the future, practically does this really matter? Does it really have any impact at all for an average user, where, I suspect, the up-front costs of JIT never actually pay themselves off. This isn't intended to be Luddism, and these improvements will benefit future apps, but so much is made about JavaScript performance (see the hoopla about JIT being disabled for embedded browsers on iOS), yet I seriously doubt it makes an ounce of difference in the real world, where the overwhelming majority of the performance limitations exist in the DOM.

leeoniya 14y ago
when it comes to complex web apps, it makes a huge difference. big data is coming to browsers in the form of massive typed Arrays from canvas and maybe soon, audio and video. We're talking about hotspots that get executed 10M+ times. These aren't your grandma's onclick handlers.
- corresation 14y ago
  when it comes to complex web apps, it makes a huge difference. Such as what? Give some examples. Further -- as a developer -- I cannot fathom "big data coming to browsers". This is racing tires on street cars: Theoretically useful, but of absolutely zero relevance for the overwhelming majority of users. Never has there been an actually practical benchmark of javascript engines and legitimate, real-world websites. Instead it's all nonsense like Sunspider. And don't misunderstand -- this actually can be a net negative for users because what benefits a 10M iteration loop is of negative consequence to an occasionally run event handler.
  - leeoniya 14y ago
    i'm doing interactive image analysis in canvas. i have pixel iteration/algo loops that easily hit 10M. my canvases are typically 1550x2006. mozilla also demoed js decoding H.264 video in realtime, the utility of which is of course questionable... the point is, though, that typed arrays are already a reality, and they are enormous. you can argue about how good an idea that was, but now that they're here, JITs are absolutely necessary.

simonsarris 14y ago

MAJOR EDIT: The first tests I accidentally ran against aurora (22a) and not the nightly (23a). Running against the nightly, the numbers are much closer, though sometimes better on either 21 or 23a for some simple things. But running the typed array/pixel manipulation test, 23a seems twice as fast as the beta! http://i.imgur.com/x2otAI1.png http://i.imgur.com/x2otAI1.png Please feel free to confirm using http://jsperf.com/canvas-pixel-manipulation/6 http://jsperf.com/canvas-pixel-manipulation/6 Original post below, with erroneous benches removed: ~~~ Hmm, I have a lot of HTML canvas-based performance tests, so I plucked two of them to give a small comparison a go. Comparing the results of these simple exercises doesn't seem too promising. The first test I used was a simple one that merely sets every canvas propery (some can be time consuming): http://jsperf.com/can-attribs http://jsperf.com/can-attribs And the second one tests different ways of filling single pixels: http://jsperf.com/filling-pixels http://jsperf.com/filling-pixels From a practical standpoint canvas performance matters very much to me, but my tests probably aren't the best metric. Are there better tests that could be used to see the difference between the old and new compilers here? edit: on a test comparing typed arrays to plain, performance seemed nearly (merely?) identical: http://jsperf.com/canvas-pixel-manipulation/6 http://jsperf.com/canvas-pixel-manipulation/6

leeoniya 14y ago
i also have a lot of canvas-heavy code and use typed arrays pretty extensively. i think that mozilla's canvas implementation is actually the bottleneck here, not the JS. chrome's canvas proves to be much faster, though.
- leeoniya 14y ago
  i reported the issue about a year ago, FYI. https://bugzilla.mozilla.org/show_bug.cgi?id=746773 https://bugzilla.mozilla.org/show_bug.cgi?id=746773
  - bzbarsky 14y ago
    That issue is basically fixed in most sane code, actually; I just resolved it as such. For example, on http://jsperf.com/pixel-pre-rendering/5 http://jsperf.com/pixel-pre-rendering/5 I see identical numbers for the two versions of the test.

VeejayRampay 14y ago

Damn this browser business is getting crazy these days. I wonder if we'll look at how the browser performs in say 5 years from now with the sense that 2013 was basically the dark ages. Exciting times...

ConstantineXVI 14y ago
Dark Ages would imply that progress was set back significantly by some catastrophic event (ie: the fall of Netscape). Renaissance would be a more apt term, given the rapid advances we're going through.
- Teckla 14y ago
  Dark Ages would imply that progress was set back significantly by some catastrophic event (ie: the fall of Netscape). Some of us would argue that JavaScript itself was that catastrophic event. No, really -- I'm not trolling. It's no longer reasonable for people to deny that JavaScript doesn't lend itself well to optimizing run-time performance. These Herculean efforts are impressive, but perhaps it's time to fix the language, even if that breaks backwards compatibility.
  - DigitalJack 14y ago
    I've pretty much ignored javascript until this week. What exactly is wrong with it? Perhaps that is too broad. Can you give an example of something in javascript that impedes runtime performance optimization?
  - aroman 14y ago
    They're working on it; it's called ES6. But in terms of your claim that "It's no longer reasonable for people to deny that JavaScript doesn't lend itself well to optimizing run-time performance", I'm not sure what to say to that. JavaScript code is some of the fastest interpreted code around, and projects like asm.js take that even farther. It's a phenomenally beautiful and expressive language once you get around the fact that it has some minor warts. I might have agreed with you 10 years ago, but I don't think there claim that JS simply doesn't lend itself to being performant is true at all -- all the evidence I see, both as a web JavaScript and Node.js developer, and following the recent relative news, has pointed me to quite the opposite: javascript is doing great right now.

antonios 14y ago

The amount of innovation coming from Mozilla has been staggering the last year. IonMonkey, asm.js, impressive memory usage improvements (Firefox is now by far the least memory hungry browser among the modern ones), new baseline jit...Rock on, Mozilla.

Offler 14y ago
And Rust, linked to that Servo seems very interesting.
nnethercote 14y ago
> impressive memory usage improvements (Firefox is now by far the least memory hungry browser among the modern ones) What evidence do you base this on -- your own experience, or that of others, or measurements such as those done by Tom's Hardware, or something else? I'm not disputing your claim, I'd just like to know :)
- haksan 14y ago
  http://lifehacker.com/5976082/browser-speed-tests-chrome-24-firefox-18-internet-explorer-10-and-opera-1212 http://lifehacker.com/5976082/browser-speed-tests-chrome-24-... http://www.zdnet.com/time-to-take-another-look-at-firefox-7000009692/ http://www.zdnet.com/time-to-take-another-look-at-firefox-70... http://www.tomshardware.com/reviews/chrome-17-firefox-10-ubuntu,3129-14.html http://www.tomshardware.com/reviews/chrome-17-firefox-10-ubu... googling is not rocket science. and these three links are only the newest ones, there are more from 2011.
  - antonios 14y ago
    There's also Mozilla's own "Are we slim yet?" interface to track their progress in memory usage. https://areweslimyet.com/ https://areweslimyet.com/ You can even see the bugs that lead to memory regressions there.
    - nnethercote 14y ago

sergiosgc 14y ago

How feasible would it be to have webservers compile javascript and serve it to the browser already preprocessed (as far as possible)? The same URL could be used, but a different mime type acceptance signaled by the browser using the Accepts header. The webservers, instead of returning text/javascript would return application/javascript+moz22. Then, most of this race towards hotspot optimization would be less important.

pestaa 14y ago
I do not trust 99 servers out of 100 including not only those I intend to communicate with but others sitting in the middle of my connection, to deliver the same binary my browser would render in a few milliseconds. The web is a wild place, let's not increase our attack surface.

crucio 14y ago

is there a way to signal to the browser that I'd like all of my JavaScript to be compiled as best as possible and that I don't mind my users waiting while this happens? Could this be useful for complex games where start-up speed may not be deemed as important as runtime performance?

shardling 14y ago
In a sense that's what asm.js is. Obviously not quite what you're asking for, though.
jomohke 14y ago
If you compiled immediately you would probably find that your games performed much worse, because the compiler would have very little information about the functions and the kind of arguments that will be passed to them. Once a function has run many times, the compiler can use the gathered statistics (such as knowing that the arguments were always floats) to produce better optimised machine code (such as using float-specific ops, and eliminating code paths that expect arguments other than floats). This is a common tradeoff for all JITs; Should I wait longer to produce better code, or compile sooner to run the faster code earlier? You can play with this number in most Java JVMs (OpenJDK or Sun/Oracle) using the argument "-XX:CompileThreshold". This sets how many times a function should run before it is compiled. It defaults to about 1500 for a client VM and 10000 for a server VM. As mentioned in a sibling comment, asm.js is a partial alternative to this tradeoff, as your asm.js code specifies all data types ahead of time, and hence they can be compiled up-front fairly well.

ritonlajoie 14y ago

I'm not a javascript nor browser pro but I wonder why the compilation is done client side. Cant's the servers do it and send the jit code to the client instead?

sjwright 14y ago
Too many combinations of operating system, cpu, browser, browser version -- the server would need to have a huge number of versions built and cached. And then you need to ensure your server continually has support for all the latest browsers. But even that pales in comparison to the biggest reason, which is security. In order to run fast, the compiled version needs to be "trusted" to do the right thing; by allowing the server to send pre-compiled code, you're opening up a huge number of attack vectors.

tambourine_man 14y ago

Also, to remark on recent happenings… given the recent flurry of news surrounding asm.js and OdinMonkey, there have been concerns raised (by important voices) about high-level JavaScript becoming a lesser citizen of the optimization landscape. I hope that in some small way, this landing and ongoing work will serve as a convincing reminder that the JS team cares and will continue to care about making high-level, highly-dynamic JavaScript as fast as we can. Great answer.