A few points as an outsider about how asm.js could be considered a new VM:
- PNaCl is different from a true "plugin technology" by being built into the browser, open, etc. Although browser vendors are not likely to stop competing on JavaScript speed, in a world where PNaCl is the "correct way" to run C/C++ code, C/C++ compiled to JavaScript will become far less important to optimize compared to hand-written, dynamic JavaScript: although of course there is overlap, the priorities are fairly different.
- For optimum performance, some sort of ahead-of-time compilation is absolutely required. Although a "sufficiently smart compiler" might include ahead-of-time compilation for functions whose types are statically known or speculative specialized compilation in general, I do not think any JS engine currently does that or will do that soon, so in practice you're talking about a separate code path for asm.js. Not even close to the size of something like NaCl, but there.
- Similarly, I have heard claims that a custom parser provides a significant speedup, and it's listed as a future project for OdinMonkey. This is probably only a tiny bit of code, but it also requires an explicit commitment to asm.js.
- 50% C speed is not enough - I think everyone would like this to approach 100%. Although I don't think OdinMonkey currently does this, there would probably be a speedup by using virtual memory tricks - either reserving 4GB of address space for the heap to avoid having to explicitly check the validity of an array index, or doing something similar to NaCl, plus possibly even trying to detect and convert pointer-like integer arguments to real pointers. I think this is a good thing and should happen, but it very much falls into the territory of custom asm.js VM.
- You might also get a performance increase by just replacing the optimizing compiler wholesale with LLVM? I don't know if this would actually yield a significant improvement, because a lot of the advanced optimizations would have already happened at an IR level in emscripten, and I suppose browser makers would be likely to incorporate whatever improvements into their JS engines rather than actually adopting LLVM, but I'm not sure I'd rule it completely out...
- Some proposed JavaScript features are really mostly useful only for asm.js: multi-threaded access to ArrayBuffers plus locks (and there's no way asm.js can be competitive without that); function futures; GC hooks for JVM->asm.js.
- And some that, while generally useful in some cases, feel aimed towards asm.js: BinaryData, value objects, SIMD (ala Dart, not Intel's high level stuff).
AOT compilation really isn't required; sometimes JIT compilation is a real winner (like in those startup time cases Alon mentioned, but also in cases with constrained memory, like mobile) - sometimes 90% of the code in your app isn't going to be running most of the time, and it's much better to have 1-2ms pauses for things to be JITted or larger pauses behind a loading screen.
The AOT compilation for asm.js is arguably a win primarily because it produces deterministic behavior (existing heuristics in SpiderMonkey and V8 are an ENORMOUS PAIN) and because it enabled them to get their existing IonMonkey code generator to produce better output. Those both justify the effort, I think, especially given how cheap it was to implement.
All of those proposed features in your last two bullet points are useful for JSIL, which does not use asm.js. I can understand how people with a narrow understanding of JS look at these things and think 'these are all VM features for asm.js disguised as JS APIs!' because they don't understand, but they simply aren't. IIRC, Emscripten doesn't even benefit from Binary Data or Value Objects because it already has a virtual heap; that's not going to change.
With constrained memory, ahead of time wins by a long shot thanks to demand paging. You only need to allocate physical memory for code that is actually hit.
With JIT code, you need to allocate space for the bytecode, allocate space for the linking, relocations, or whatever substitute you use (since bytecode typically isn't prelinked), allocate space for the JIT itself, and allocate space for the JITted output.
Sorry, I should be clearer - the kind of AOT compiles that OdinMonkey currently does do not benefit from demand paging, because the entire app is compiled from scratch at startup each time. If it generated executables on disk, then you could demand-page them in, just like the output from a traditional compiler. But I don't know if that has been proposed anywhere.
I guess you could allocate guard pages for each function in the application and AOT-compile each function once on demand to simulate demand paging? Hm.
Emscripten certainly should benefit from value objects because they are required to deal with 64-bit integers and 32-bit floats efficiently.
Supporting asm.js as a compilation target for managed languages is very much a goal (according to the FAQ anyway), including binary data and somehow garbage collecting the same within asm.js. I think this includes JSIL eventually, but it doesn't really matter whether you call it asm.js or not: those features fall under the general umbrella of things that are only necessary for compiling high performance, statically typed code to JavaScript, which would become a fairly unimportant use case if the "correct way" to run such code was via PNaCl; thus, they can be considered a parallel technology stack to PNaCl. I personally think that since it's still a way smaller stack and for other reasons, JavaScript is the better approach, but I don't agree that this is all stuff that is orthogonal or going to be done anyway.
> in a world where PNaCl is the "correct way" to run C/C++ code
PNaCl will never be the correct way to run C/C++, because it will never be standardized. The implementation itself defines what it is, it will never have a spec, as it depends on LLVM. Writing a spec for the standardization of PNaCl means you have to also write a spec for LLVM. It will never happen and the only browser that will support it will be Chrome. And unless Chrome wins a monopoly on web browsers, PNaCl will never be part of the web.
It also baffles me that people don't remember what happened with IExplorer and ActiveX. Are people here so young as to haven't lived the early 2000?
What makes PNaCl different from ActiveX anyway? Is it because of the Google branding? Microsoft was once considered to be cool you know. And IExplorer 5 was a kickass browser for its time. Is it because PNaCl has source-code? That doesn't warm me much. Mozilla and other browser vendors could have reversed engineered ActiveX. So what makes them so different that this time it's OK?
> 50% C speed is not enough
We managed to live just fine without C/C++ on the web. We could continue living without it for a very long time. What do you think is better, running C code at 50% speed, or not being able to run C code at all? And people have been using and running with languages that run at 2% of C. Achieving 50% of C, assuming it is true, is sensational considering the benefits (like extreme portability).
Maybe it won't be standardized. And maybe websites will start instructing users to use Chrome, or simply publish to the Chrome Web Store. If asm.js takes off, I think it will work, but right now it's one browser maker competing against a kit which provides 90% speed, today, with multithreading and a real debugger, and which, despite its flaws, seems cleaner and saner to many developers (I'm sure you've seen the many kneejerk reactions to JavaScript-as-bytecode), never mind other browser makers which seem fine with none-of-the-above (remember, today, if you even want to use WebGL, you're asking a significant portion of users to switch browser). So despite the hype, I'm not sure asm.js will receive enough support in the next few years to succeed.
The difference between asm.js and PNaCL is that asm.js doesn't need to receive support for it to succeed - asm.js code will get faster and faster, even if browser vendors do not make any effort to support it, virtue of it being a subset of Javascript.
> today, if you even want to use WebGL, you're asking a significant portion of users to switch browser
That's not really true. WebGL is supported in Firefox, Chrome, Opera and Safari. For IExplorer there's a browser plugin available that can add the necessary support.
Of course, having to install a browser plugin for IExplorer is not ideal. Microsoft decided to wait before implementing it for IExplorer versions 9 and 10 due to valid security concerns [1]. Even so, IExplorer 11 may include such support if the Windows 8.1 preview is to be believed.
> I'm sure you've seen the many kneejerk reactions to JavaScript-as-bytecode
I haven't read a single knee-jerk reaction that was informed and justified. The only anti-reaction I've read so far has been from Vyacheslav Egorov, a Google engineer, that's arguing that asm.js is not needed because we haven't reached the limit of where we can take Javascript in terms of performance and that in his opinion it can fragment the web if browser vendors concentrate on optimizing just the asm.js subset, instead of Javascript as a whole.
However, the same arguments can be said about PNaCl. Even inside Google people have mixed opinions about Javascript versus PNaCl and Dart.
> a kit which provides 90% speed, today, with multithreading and a real debugger, and which, despite its flaws, seems cleaner and saner to many developers
I hope you're thinking of something else other than GDB, because if that's the sane debugger you're talking about, then I'll take Firebug any day of the week, thanks ;-)
Javascript does have multithreading by means of web workers, available even in IExplorer since version 10.
Also, lets assume for the sake of the conversation that in general developers really do consider PNaCl to be saner, even though I doubt it. Well, guess what - the resulting apps are not web apps. So why target Chrome with PNaCl, when develpers could be building native apps instead with real native experience? The reasons one wouldn't want to go native have to do with the inherent advantages of the open web. And PNaCl has none of them.
It is very hard to do, and LLVM has been difficult to use as a JIT in past projects (Unladen Swallow, for example).
However, Apple is experimenting with this in their FTL (fourth tier LLVM-based) JIT project in JSC. Because Apple drives both JSC and LLVM, this has the highest chance of success of any similar project, I believe, so it is very interesting to watch.
I doubt it. Such a replacement would be a huge effort to write (including integrating it with the existing VM) and maintain, and there are also political factors. Despite those, I don't think it's out of the question that it will happen some day, especially as Chrome already has a copy of LLVM, though I do think it's less relevant than the other stuff I mentioned.
Sure it definitely would be a lot to implement _now_, but llvm was released roughly 5 years before v8. The v8 team totally could have chosen it for a compiler back end (code generation). My observation was simply that they didn't, and I believe there probably was a reason for it (though I can't speak to it).
In hindsight, it probably would've made more sense for Google to utilize llvm as a compiler IR in v8 than as a virtual machine as in PNaCl. [1]
- PNaCl is different from a true "plugin technology" by being built into the browser, open, etc. Although browser vendors are not likely to stop competing on JavaScript speed, in a world where PNaCl is the "correct way" to run C/C++ code, C/C++ compiled to JavaScript will become far less important to optimize compared to hand-written, dynamic JavaScript: although of course there is overlap, the priorities are fairly different.
- For optimum performance, some sort of ahead-of-time compilation is absolutely required. Although a "sufficiently smart compiler" might include ahead-of-time compilation for functions whose types are statically known or speculative specialized compilation in general, I do not think any JS engine currently does that or will do that soon, so in practice you're talking about a separate code path for asm.js. Not even close to the size of something like NaCl, but there.
- Similarly, I have heard claims that a custom parser provides a significant speedup, and it's listed as a future project for OdinMonkey. This is probably only a tiny bit of code, but it also requires an explicit commitment to asm.js.
- 50% C speed is not enough - I think everyone would like this to approach 100%. Although I don't think OdinMonkey currently does this, there would probably be a speedup by using virtual memory tricks - either reserving 4GB of address space for the heap to avoid having to explicitly check the validity of an array index, or doing something similar to NaCl, plus possibly even trying to detect and convert pointer-like integer arguments to real pointers. I think this is a good thing and should happen, but it very much falls into the territory of custom asm.js VM.
- You might also get a performance increase by just replacing the optimizing compiler wholesale with LLVM? I don't know if this would actually yield a significant improvement, because a lot of the advanced optimizations would have already happened at an IR level in emscripten, and I suppose browser makers would be likely to incorporate whatever improvements into their JS engines rather than actually adopting LLVM, but I'm not sure I'd rule it completely out...
- Some proposed JavaScript features are really mostly useful only for asm.js: multi-threaded access to ArrayBuffers plus locks (and there's no way asm.js can be competitive without that); function futures; GC hooks for JVM->asm.js.
- And some that, while generally useful in some cases, feel aimed towards asm.js: BinaryData, value objects, SIMD (ala Dart, not Intel's high level stuff).