top | item 46645981

(no title)

FjordWarden | 1 month ago

Ah, I think I found the reason as to why WebAssembly (in a browser or some other sandboxed environment) is not a suitable substrate for near native performance. It is a very ironic reason: you can't implement a JIT compiler that targets WebAssembly in a sandbox running in WebAssembly. Sounds like an incredibly contrived thing to do but once speed is the goal then a copy-and-patch compiler is a valid strategy for implementing a interpreter or a modern graphics pipeline.

discuss

order

fwsgonzo|1 month ago

This is true. A multi-tier JIT-compiler requires writable execute memory and the ability to flush icache. Loading segments dynamically is nice and covers a lot of the ground, but it won't be a magic solution to dynamic languages like JavaScript. Modern WASM emulators already implement a full compiler, linker and JIT-compiler in one, almost starting to look like v8. I'm not sure if adding in-guest JIT support is going in the right direction.

syrusakbary|1 month ago

> you can't implement a JIT compiler that targets WebAssembly in a sandbox running in WebAssembly

That's not completely true. With dynamic linking (now supported in WASIX), you can generate and link Wasm modules at runtime easily.