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

31–40 of 96 posts

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

#31

Post by jchw »

gravypod wrote: post #25
jchw wrote: post #24

Earlier quoted context omitted.

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 ide…

The JVM had many chances to realize that goal. Java applets, J2ME, etc. I’m not sure which particular issue really kept it from keeping mindshare. I don’t think the virtual machine itself was ever really the problem.

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.

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

#32

Post by ineedasername »

kbumsik wrote: post #11
techntoke wrote: post #6

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?

Here's one: https://www.fastly.com/blog/hijacking-control-flow-webassemb...

I'm not sure any of this is any worse than javascript though.

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

#33

Post by snek »

gravypod wrote: post #25
jchw wrote: post #24

Earlier quoted context omitted.

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 ide…

in v8 at least, we just plugged wasm into v8's existing jit. no need to make a new one from scratch.

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

#34

Post by sanxiyn »

johncolanduoni wrote: post #27
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?

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

They are aaload and aastore.

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

#35

Post by Twirrim »

Arbalest wrote: post #20
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?

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.

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

#36

Post by saagarjha »

lightgreen wrote: post #29
_nhynes wrote: post #18

Earlier quoted context omitted.

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).

> it’s not possible to statically validate that addresses are within linear memory

It might just be me, but I don't think this is what the parent comment said.

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

#37

Post by saagarjha »

writepub wrote: post #17
mises wrote: post #3

"Run a fast, sandboxed bytecode outside of the sandbox by compiling it into a binary" so just a binary. I'm not sure I understand why you would use wasm here. No one writes wasm; you compile to it (usually from llvm ir). Why couldn't you just go straight from llvm ir to a binary; skip the wasm? I suspect I'm missing something here, but it doesn't seem to make sense.

Because LLVM IR is CPU-Arch specific. For instance, IR for x86 cannot be used on ARM CPUs, which is also the reason why Apple's bitcode representation intended to make apps portable, doesn't cross the iOS (ARM) MacOs (x64) boundary, unless ARM ISA emulation is happening in Mac (like in Marzipan?)

Marzipan is not an ARM emulation layer.

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

#38

Post by saagarjha »

jchw wrote: post #31
gravypod wrote: post #25

Earlier quoted context omitted.

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 ide…

The JVM had many chances to realize that goal. Java applets, J2ME, etc. I’m not sure which particular issue really kept it from keeping mindshare. I don’t think the virtual machine itself was ever really the problem. 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…

> I’m not sure which particular issue really kept it from keeping mindshare.

The fact that it was bundled as a browser plugin, mostly.

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

#39

Post by lightgreen »

saagarjha wrote: post #36
lightgreen wrote: post #29

Earlier quoted context omitted.

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).

> it’s not possible to statically validate that addresses are within linear memory It might just be me, but I don't think this is what the parent comment said.

“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.

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

#40

Post by saagarjha »

lightgreen wrote: post #39
saagarjha wrote: post #36

Earlier quoted context omitted.

> it’s not possible to statically validate that addresses are within linear memory It might just be me, but I don't think this is what the parent comment said.

“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.
Post reply on HN