> JS running on a general VM would be slower. That's against the interests of the user.
What do you base this on? It's sounds like an unsupported assumption regarding the complex technical constraints involved in implementing a general purpose VM and JIT.
Putting the technical specifics aside, intuitively, why would the general VM be slower, especially since the requirement to support JavaScript would be obvious to everyone involved from day 1?
>> JS running on a general VM would be slower. That's against the interests of the user.
> What do you base this on? It's sounds like an unsupported assumption
No, he is entirely correct.
JavaScript and most dynamic languages do not run at full speed on static-language VMs like the JVM and .NET. This is despite tremendous efforts and motivation to run those languages quickly on such environments, see for example Microsoft's SPUR paper and everything it has done in the CLR to speed up dynamic languages.
The fact is, despite all those efforts, even Microsoft did not implement JS on .NET in IE. This despite Microsoft more than anyone having the capability and moreso the motivation ("everything on .NET"). Microsoft gave up and implemented a new JS engine in native code, and it made that new native JS VM a peer of .NET in Windows 8.
The reasons for this are technical: We do not know how to make a single VM that runs all languages quickly. It's very difficult to do! Dynamic languages need hand-crafted PICs for example, which are extremely difficult to make portable and safe, which is necessary for a VM on the web. Also, low-level details like even how to implement numbers are significant: NaNboxing for example is used in most JS engines, but it probably doesn't make sense in a static language VM. Having both NaNboxed numbers and 'normal' ones in one VM is cumbersome and complex.
> JavaScript and most dynamic languages do not run at full speed on static-language VMs like the JVM and .NET. This is despite tremendous efforts and motivation to run those languages quickly on such environments, see for example Microsoft's SPUR paper and everything it has done in the CLR to speed up dynamic languages.
I'd argue the opposite regarding tremendous efforts and motivation; dynamic languages were an after-thought for both the JVM and .NET, and on the JVM side you've only seen any attempts to improve performance recently, with invokedynamic for Java 7.
The investments here occurred long after the VMs were developed.
> The reasons for this are technical: We do not know how to make a single VM that runs all languages quickly.
The same applies to compilers across the board; we do not know how to make a compiler that applies all possible optimization available to code always, either. I still have to manually vectorize critical paths, re-order code (sometimes in C!) to help the compiler avoid pipeline stalls, etc.
Instead, we do the best general purpose job we can, and it's usually more than fast enough.
What we're talking about here is a VM that has JS support as its first-order target. Using the JVM and CLR as performance examples here -- given what they were built for, and when -- is not particularly valid.
Speaking to NaN-boxing in particular; it's one solution to the problem, but not the only one. I'm going to remain unconvinced here, given that dynamic languages have almost always been a late, second-tier concern for anyone investing serious R&D in the development of a VM/JIT/compiler.
All that said ...
> The fact is, despite all those efforts, even Microsoft did not implement JS on .NET in IE. This despite Microsoft more than anyone having the capability and moreso the motivation ("everything on .NET"). Microsoft gave up and implemented a new JS engine in native code, and it made that new native JS VM a peer of .NET in Windows 8.
Even given the above, implementing a custom optimized JavaScript VM -- even if it was only available in JS-only case -- would not be a failure scenario.
> I'd argue the opposite regarding tremendous efforts and motivation; dynamic languages were an after-thought for both the JVM and .NET, and on the JVM side you've only seen any attempts to improve performance recently, with invokedynamic for Java 7.
> The investments here occurred long after the VMs were developed.
That's a valid point. It is possible that some entirely new kind of VM could work, that was designed from the ground up for both static and dynamic languages. But I don't think we have any good idea of such a thing!
Until we do know how to do this, replacing the JS VMs in browsers would slow everything currently running. And adding another VM alongside it would decrease speed in other ways (see for example the papers that the Apple dev mentions in the WebKit discussion for why Apple opposes adding the Dart VM into WebKit).
I'm not ready to take it as a given that we can't build a general purpose VM capable of running JS at or very near current speeds, but it's also not a solved problem.
What do you base this on? It's sounds like an unsupported assumption regarding the complex technical constraints involved in implementing a general purpose VM and JIT.
Putting the technical specifics aside, intuitively, why would the general VM be slower, especially since the requirement to support JavaScript would be obvious to everyone involved from day 1?