No, WASM is slow. As a developer of TeaVM I can claim this. First of all, JS engines been developed for many years, while WASM is a new technology and browser engines don't optimize it well. Another reason is WASM was not designed to run languages like Java, at least in version 1.0. Here are the reasons:
* To make GC work properly you have to maintain GC roots. GC roots are static fields + variables in stack. There's no way in WASM to walk the stack! You have to maintain your own shadow stack, losing performance. In case of generating native code (e.g. x86/64) you can access native stack freely and finding GC roots produces no overhead (which is already done by JS engines).
* To make exceptions work properly, you need to walk the stack, and not only read it, but also write to it (in case of x86, update RSP direcly). This is not supported by WASM. But JS engines already do it natively, with no overhead for exceptions, until you throw then. With WASM you have to check after each call whether the exception was thrown or not, and that affects performance.
* In native environment you can do memory protection magic for different runtime things, e.g. to detect null pointer access, and that's not possible with WASM.
* In WASM you can't mutate code, so it makes impossible to implement lazy initialization logic without some overhead. JavaScript engines can detect that certain function got changed and de-optimize calling function, then optimize it again.
So, according to my experience and my benchmarks, compiling Java to JavaScript is a better option, both from performance and code size standpoint. WASM team is working on GC and exception handling, but they do it slowly and current design is far from perfect. I failed to convince them to just give access to stack, perhaps in some limited way (for security reasons).
And yes, the lack of access to stack even affects C code. For example:
* To make GC work properly you have to maintain GC roots. GC roots are static fields + variables in stack. There's no way in WASM to walk the stack! You have to maintain your own shadow stack, losing performance. In case of generating native code (e.g. x86/64) you can access native stack freely and finding GC roots produces no overhead (which is already done by JS engines).
* To make exceptions work properly, you need to walk the stack, and not only read it, but also write to it (in case of x86, update RSP direcly). This is not supported by WASM. But JS engines already do it natively, with no overhead for exceptions, until you throw then. With WASM you have to check after each call whether the exception was thrown or not, and that affects performance.
* In native environment you can do memory protection magic for different runtime things, e.g. to detect null pointer access, and that's not possible with WASM.
* In WASM you can't mutate code, so it makes impossible to implement lazy initialization logic without some overhead. JavaScript engines can detect that certain function got changed and de-optimize calling function, then optimize it again.
So, according to my experience and my benchmarks, compiling Java to JavaScript is a better option, both from performance and code size standpoint. WASM team is working on GC and exception handling, but they do it slowly and current design is far from perfect. I failed to convince them to just give access to stack, perhaps in some limited way (for security reasons).
And yes, the lack of access to stack even affects C code. For example:
int i = 23; foo(&i);