InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed
innative.dev
innative.dev
The only reason we haven’t already gotten to 99% native speed is because WebAssembly’s 32-bit integer indexes break LLVM’s vectorization due to pointer aliasing. Once fixed-width SIMD instructions are added, native WebAssembly will close the gap entirely, because this vectorization analysis will have happened before the WebAssembly compilation step.
The differentiator for InNative seems to be the ability to bypass the sandbox altogether as well as additional native interop with the OS. Looks promising!
Rust and Go have support for many targets but not as many as other compilers (GCC), a coverage problem that can be fixed by using WASM as intermediate and porting a WASM Runtime to that architecture.
Something like Innative would also enable desktop applications to be independent of the OS and architecture. The same binary would run on x86_64 Windows, PowerPC Mac and ARMv8 Linux.
It's basically Java but you don't have to use Java to get all the good parts.
(Disclaimer: I know the main dev of innative and do some WASM work myself)
Yeah, instead it matters which WASM runtimes it supports and which archs those runtimes support.
But that's ok, we just need one more layer of abstraction to fix the whole mess.
https://en.wikipedia.org/wiki/UNCOL https://en.wikipedia.org/wiki/Architecture_Neutral_Distribut...
There is already plenty of companies that deployed WASM on their stack (like Ebay, they use Wasm for their barcode scanner), it's not going away any time soon.
https://docs.oracle.com/javase/tutorial/deployment/applet/ma...
"WebAssembly’s 32-bit integer indexes break LLVM’s vectorization due to pointer aliasing. Once fixed-width SIMD instructions are added, native WebAssembly will close the gap entirely, because this vectorization analysis will have happened before the WebAssembly compilation step."
We're well on our way.
What extra benefit does this provide, except avoiding Oracle?
Jokes aside, why are you comparing these two very different virtual machines? WASM is a general purpose VM, JVM is not. For example, you won’t find a Rust JVM target any time soon. (Not to suggest that the JVM is strictly limited to Java, it isn’t obviously, but it is not nearly as suited to being a target for lower level languages. Also, the security model is very different.)
Wasm is a good idea but it's going to need to reimplement a lot of existing code (optimizing + jit).
Doable and maybe it will convince people to do what has been a great idea first widely deployed by Java: compiled language in an abstract machine.
Still, since the Java platform didn’t capture this use case of a general purpose abstract machine, it makes a whole lot of sense to develop something like WASM. It’s a much more neutral platform to build on.
In particular we actually don’t need to go through all of the things Java went through; we have a wealth of knowledge about what things work and what things don’t work so well. Yes, its a new JIT, but not that new: from my understanding typically the JavaScript JIT machinery is reused for the WASM JIT in browsers.
The fact that it was bundled as a browser plugin, mostly.
Where the hell did you get that idea? WASM can be used as just another frontend for javascript JIT engines like V8 or SpiderMonkey.
WASM has been designed from the ground up with portability, security, and stability in mind. It is also a lower target than JVM bytecode, which makes it more suitable to represent languages like rust and go. It has also been designed to take advantage of the sandboxed JIT engines that browsers already have for running javascript. Additionally, WASM is an open standard that anyone can contribute to, which is something that is greatly valued on the web.
Actually, we didn't really try JVM in the browser. We tried it as a plug-in like Flash. The JVM didn't have access to the DOM like Javascript and WASM will have.
Better read the documentation?
https://docs.oracle.com/javase/tutorial/deployment/applet/ma...
So, none of them out-of-the-box like Javascript. Given, it didn't really work as far out as 2005[1] which is 10 years after Javascript was introduced, I stand by my original statement.
With WASM it will even get better, Flash that one cannot disable.
WASM code generated from languages like C is still open to internal memory corruption caused by out of bounds accesses.
If they were fully serious about security, memory tagging would be supported.
The only bit being monetised is the Oracle compiled and distributed version of the JVM. If you don't want to pay Oracle, just use OpenJDK, which has all of the same hotspot JIT stuff.
a] Yes you can make android apps run on AOSP, but as many comment with regards to Huawei losing their Android licence, it will remove access to a lot of API infrastructure that isn't even Google specific.
edit: * caused formatting rather than being a note
1 - I always read what I get proposed to install and disable what I don't care about.
2 - The JDK didn't had such "feature", only the consumer JRE
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...
Any source?
I'm not sure any of this is any worse than javascript though.
WASM is equivalent to early 80s ISAs but with different opcodes. Native WASM would be most efficient.
Writing an complete compiler backend/asm/ld is a significant undertaking which is only worthwhile for very stable architectures.
The main difference in Bytecode/WASM is memory model and branching support. But you could say that both are equivalent to 80's ISA's.
Precompiled Java is closer to WASM than many would like to admit, so I expect performance to be similar in the long run. This isn't so bad, Java reaches over half native speed on many benchmarks. It's amazing that we'll be able to run untrusted code so quickly
It might just be me, but I don't think this is what the parent comment said.
E. g. WASM stack local variables and globals are statically validated. Compiler can translate loads and stores to locals and globals to simple movs. There are no additional runtime checks, no overhead. Unlike linear memory.
Since OS/process virtual memory bound checking is handled by the hardware, the one time setup above will lock down WASM memory access to within the 64MB, without software runtime overheads.
This is exactly why WASM memory was picked to be linear (unlike virtual memory that can have holes in continuity)
This phrase “host is still sandboxed from the module even without virtual memory” confused me. Because technically any interpreter (even qemu) can run without virtual memory with more or less expensive runtime checks.
It sure looks like a language to me, like some sort of assembly language.
https://webassembly.org/getting-started/advanced-tools/
https://developer.mozilla.org/en-US/docs/WebAssembly/Text_fo...
granted this is a textual representation (very useful in certain circumstances) but that is semantics. Having done plenty of assembly, I don't see a huge distinction here.
Also, this is not "JITed bytecode", it is compiled AOT.
PNaCL died in favour of WebAssembly due to politics.
With Chrome today's might, the decision would most likely be a different one.
It’s a shame that the x32 ABI is almost abandoned nowadays, it has some modest improvements for applications that don’t need that much memory.
(The point being that 5% slowdown is a drop in the bucket compared to what we've already lost due to Intel's chip design problems. AIUI, HT is a 15-20% slowdown, and SE was another 20% slowdown.)
Did the Mill CPU finally get first silicon? ;)