41–50 of 96 posts
Earlier quoted context omitted.
We already have a portable, stable, well specified cross platform language. It’s called Java. What extra benefit does this provide, except avoiding Oracle?
Wasm bytecode is lower-level than JVM bytecode, so I believe it's a much easier compilation target for a variety of source code languages.
Earlier quoted context omitted.
“Statically validated” AFAIU means there are no runtime checks. 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.
As far as I could parse that comment, it's saying that function calls are statically validated and that memory is linear. Not that all memory accesses can be statically validated.
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.
Earlier quoted context omitted.
Besides the point about already trying out Java Applets, Why would you dismiss the Oracle avoidance? Oracle recently moved with Java to show a strong preference to monetising it, whereas lots of people on the web cannot afford any licencing just to be able to make stuff to run on the client machine. It is actually a very strong feature of it.
It's a really funny monetisation move, releasing everything as open source, putting it all in openjdk (which has been the language reference spec for a while anyway) 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
Earlier quoted context omitted.
We already have a portable, stable, well specified cross platform language. It’s called Java. What extra benefit does this provide, except avoiding Oracle?
We already tried JVM in browsers, remember java applets? I sure remember the security and compatibility problems :) 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 h…
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.
Earlier quoted context omitted.
Because WASM is already bad for user security, they want to make it worse.
> WASM is already bad for user security Any source?
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 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.
WebAssembly on desktop and servers is maturing pretty rapidly! There are several backend interpreters already in Rust and Go (life). The native, compiled options are even faster, Fastly's Lucet compiler and runtime was one of the first to implement WASI ( https://wasi.dev/ ): https://www.fastly.com/blog/announcing-lucet-fastly-native-w... The differentiator for InNative seems to be the ability to bypass the sandbox a…