The gamedev industry will no doubt be shocked to learn that they could have just been running native with zero overhead instead of implementing and embedding various forms of scripting.
I think WASM will have a great future in the cloud, giving cloud providers can offer their services in any programming language their users want, running in a secure sandbox.
But i'm not so sure about personal devices. It would be very hard to beat Javascript code on the Web in general. So i dont know about the general purpose target future in that case, i think it will flop, except as a fancy accelerator or to virtualize things that was once outside the web.
While there will always be the case that highly optimized javascript code will be more performant, the flexibility and performance of WASM on the web and in browsers means that a significant number of high impact products and services have already made the jump to using WASM in part or in full.
As far as I understand, Hotspot is such an excellent VM arhat some languages have been adapted for it as a compilation/execution target; it‘s not particularly well suited for running other languages. Especially dynamic languages have been struggling with inefficiencies imposed by some of the Java-orientied paradigms.
WASM does not provide a garbage collector, as another example; this probably makes non-garbage-collected languages behave more predictably.
> Especially dynamic languages have been struggling with inefficiencies imposed by some of the Java-orientied paradigms.
I don’t think it is anywhere close to the truth. They are very well suited, as the JIT compiler can specialize dynamic types (and optionally deoptimize them when the type changes). There are also clojure, jruby, a python implementation, and java can also be written with significant use of reflection.
And then there is GraalVM built on top of the JVM that has truffleruby, the fastest Ruby implementation, graaljs which has very comparable performance to v8 with comparatively much less man hours , etc, all very dynamic languages.
Was that true even before `invokedynamic`, which as far as I know was specifically added to make these non-Java languages easier to port and more performant?
All of the examples you‘ve mentioned don‘t seem like trivial ports at least from an outsider‘s point of view.
The JVM itself has definitely adapted to these use cases, but it wasn‘t designed with them in mind.
You are right about the reason invokedynamic was added, but as far as I know the JVM always supported dynamic class loading (and thus class creation as well), so while not necessarily in a too performant manner, it could always be used as a runtime for even very dynamic languages. (And I think I left out Groovy which is a quite old dynamic language on the JVM).
> dynamic languages have been struggling with inefficiencies imposed by some of the Java-orientied paradigms
If you think the jvm is bad for dynamic languages, wait'll you hear about wasm!
In fact, I would expect the jvm to work much better for dynamic languages; not only does it already have a[1] gc, it has inline caching built in, which is frequently crucial for getting good performance in dynamic languages. (Though granted, as the niblings hint at, this requires type inference without invokedynamic.)
1. Arguably 'the'. I don't know of a platform with a better one.
Yes, but this is what .net does as well, it is not a reason not to add another one. WASM is lighter and has security model that the previous generations of vm-s do not provide. I don't know if this will be enough, but so far the experiment looks interesting.
Depends on whether your JS is limited by interpreter / JIT startup time or throughput. If it's the former, then the wasm module with wizer might be significantly faster.
