Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

innative.dev

Post reply on HN
Print view View original

21–30 of 96 posts

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#21

Post by protomyth »

snek wrote: post #16
MBCook wrote: post #12

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…

We already tried JVM in browsers, remember java applets? I sure remember the security and compatibility problems :)

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.

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#22

Post by nullwasamistake »

ryacko wrote: post #2

"We could break the stranglehold of i386 on the software industry and free developers to experiment with novel CPU architectures without having to worry about whether our favorite language compiles to it." WASM is equivalent to early 80s ISAs but with different opcodes. Native WASM would be most efficient.

Java Bytecode is similar to WASM, opcode wise. Bytecode purposely omits many instructions that can be done with equivalents to fit the whole ISA in single byte instructions. WASM is similar for the same reason, code density.

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

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#23

Post by gravypod »

jchw wrote: post #14
MBCook wrote: post #12

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?

Oh good point, we can just embed the JVM into browsers instead. WebAssembly’s cancelled everyone! 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 leve…

I think it is experimentally possible to target Rust -> LLVM -> JVM using this project https://github.com/davidar/lljvm

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#24

Post by jchw »

gravypod wrote: post #23
jchw wrote: post #14

Earlier quoted context omitted.

Oh good point, we can just embed the JVM into browsers instead. WebAssembly’s cancelled everyone! 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 leve…

I think it is experimentally possible to target Rust -> LLVM -> JVM using this project https://github.com/davidar/lljvm

In fact there’s almost certainly more ways, too. You could probably transpile WASM to JVM bytecode. These things are most useful when you already are in the JVM anyways, I can’t imagine most people writing software in pure Rust would jump for this, especially given that WASM has a lot to offer for this use case already and has good momentum. I see it as a better fit, with useful security guarantees and a simple design.

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#25

Post by gravypod »

jchw wrote: post #24
gravypod wrote: post #23

Earlier quoted context omitted.

I think it is experimentally possible to target Rust -> LLVM -> JVM using this project https://github.com/davidar/lljvm

In fact there’s almost certainly more ways, too. You could probably transpile WASM to JVM bytecode. These things are most useful when you already are in the JVM anyways, I can’t imagine most people writing software in pure Rust would jump for this, especially given that WASM has a lot to offer for this use case already and has good momentum. I see it as a better fit, with useful security guarantees and a simple desig…

The benefits of the JVM still stand out to me personally. Run anywhere, generate machine code at run time most place, world class optimizing compiler, battle tested & ready to deploy, integration with existing code base for gradual rewrites, etc.

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.

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#26

Post by feniv »

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 altogether as well as additional native interop with the OS. Looks promising!

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#27

Post by johncolanduoni »

MBCook wrote: post #12
sanxiyn wrote: post #7

Earlier quoted context omitted.

WebAssembly is portable, stable, and well-specified. LLVM IR is not portable (it is platform-specific), not stable (it changes between LLVM versions), and not well-specified (especially around undef). Therefore, WebAssembly is a good distribution format, LLVM IR is not.

We already have a portable, stable, well specified cross platform language. It’s called Java. What extra benefit does this provide, except avoiding Oracle?

Which Java opcode is for accessing linear memory again? I keep missing it somehow in these discussions...

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#29

Post by lightgreen »

_nhynes wrote: post #18
mises wrote: post #4

Earlier quoted context omitted.

Literally the whole point of WASM is fast, sandboxed code. It's not a language, it's an LLVM target. So why turn LLVM IR into a native binary? It's basically the same thing as "native wasm", whatever that would mean. "Native wasm" is just JITed bytecode. Either that, or you're turning it into a normal binary, in which case, why even use WASM?

You get a bit of safety because Wasm programs have statically validated function calls and operate only within linear memory. If there are no bugs in the stdlib or the bytecode compiler, then the host is still sandboxed from the module even without virtual memory.

No, it’s not possible to statically validate that addresses are within linear memory. WebAssembly implementations do runtime memory access checks (either with explicit if checks before some loads and stores or with virtual memory configuration).

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#30

Post by ineedasername »

snek wrote: post #16
MBCook wrote: post #12

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…

remember them? Some of us still have the unfortunate pleasure of using them. (Worse: the IT desktop folks have to support a very specific outdated version of IE to keep it functional. I remember hearing that's how a new vendor's "solution" would be delivered, and the facepalm I did at the time. The look on desktop support's face was a bit more pale and filled with dread.)
Post reply on HN