3 ms·

Just in Time (JIT) compilation is not possible as dynamic Wasm code generation is not allowed for security reasons. This sounds.. not right. Honestly,this is

Just in Time (JIT) compilation is not possible as dynamic Wasm code generation is not allowed for security reasons. This sounds.. not right. Honestly,this is an essential feature for allowing workloads like hot reloading code cleanly. I'm quite convinced the alleged security argument is bull. You can hot reload JS (or even do wilder things like codegen) at runtime without compromising security. Additionally, you can emulate codegen or hot reload, by dynamically reloading the entire Wasm runtime and preserving the memory, but the user experience will be clunky. I don't see any technical reason why this couldn't be possible. If this were a security measure, it could be trivially bypassed. Also, WASM bytecode is very similar conceptually to .NET IL, Java bytecode etc., things designed for JIT compilation. I kind of dislike WASM. It's a project lacking strong direction and will to succeed in a timely manner. First, the whole idea is conceptually unclear, its name suggests that it's supposed to be 'assembly for the web', a machine language for a virtual CPU, but it's actually an intermediate representation meant for compiler backends, with high-level features planned such as GC support. It's still missing basic features, like the aforementioned hot reload, non-hacking threading, native interfacing with the DOM (without Javascript ideally), low-overhed graphics/compute API support, low-level audio access etc. You can't run a big multimedia app without major compromises in it.

flohofwoe 2y ago
> Just in Time (JIT) compilation is not possible as dynamic Wasm code generation is not allowed for security reasons. Browsers definitely use a form of JIT-ing for WASM (which is a bit unfortunate, because just as with JITs, you might see slight 'warmup stutter' when running WASM code for the first time - although this has gotten a lot better over the years). ...also I'm pretty sure you can dynamically create a WASM blob in the browser and then dynamically instantiate and run that - not sure if that's possible in other WASM runtimes though, and even in the browser you'll have to reach out Javascript, but that's needed for accessing any sort of 'web API'.
- torginus 2y ago
  >Browsers definitely use a form of JIT-ing for WASM I (and the article) wasn't referring to this kind of JIT. I was referring to the ability to dynamically create or modify methods or load libraries while the app is running (like `DynamicMethod` in .NET). Afaik WASM even in the browser does not allow modifying the blob after instantiation. The thing you are referring to puzzles me as well. I initially thought that WASM would be analogous to x86 or ARM asm and would be just another architecture emitted by the compiler. Running it in the browser would just involve a quick translation pass to the native architecture (with usually 1-to-1 mapping to machine instructions) and some quick check to see that it doesn't do anything naughty. Instead it's an LLVM IR analog that needs to be fed into a full-fledged compiler backend. I'm sure there are good technical reasons as to why it was designed like this, but as you mentioned, it comes with tangible costc like startup time and runtime complexity.
  - flohofwoe 2y ago
    > Afaik WASM even in the browser does not allow modifying the blob after instantiation. ...not your own WASM blob, but you can build a new WASM blob and run that. > The thing you are referring to puzzles me as well... Yes, compilers emit WASM, but that WASM is just a bytecode (similar to JVM or .NET bytecode but even higher level because WASM enforces 'structured control flow') and needs to be compiled to actual machine code on the client before it can run, and this isn't a simple AOT compilation - in browsers at least (it used to be for a while in Firefox, but that caused issues for large projects like Unity games, which might take dozens of seconds to AOT compile). AFAIK all browsers now use a tiered approach. The WASM-to-machine-code compilation doesn't happen on the whole WASM blob at once, but function by function. For the first time a WASM function is called, a fast compilation will happen which may have slow runtime performance, from then on, 'hot functions' will be compiled with a higher tier backend which does additional optimization, is slow to compile but has better runtime performance - and AFAIK this is also quite similar to how Javascript JIT-ing works. Also from what I understand WASM compilation is more complex than just translating bytecode instructions to native instructions. It's more like compiling an AST into machine code - at least if you want any performance out of it. The only difference to JS might be that WASM functions are never 'de-optimized'.
bhelx 2y ago
The statement is correct. Wasm cannot mark memory as executable. It's effectively a Harvard Architecture. The code and memory are split. Furthermore you cannot jump to arbitrary points in code. There isn't even a jump instruction. > I'm quite convinced the alleged security argument is bull. You can hot reload JS (or even do wilder things like codegen) at runtime without compromising security. JIT here is referring to compiling native code at runtime and executing it. This would be a huge security compromise in the browser or in a wasm sandbox. > I don't see any technical reason why this couldn't be possible. If this were a security measure, it could be trivially bypassed. It's not because it's baked into the design and instruction set. You can read some more about how it works here: https://webassembly.org/docs/security/ https://webassembly.org/docs/security/ > Also, WASM bytecode is very similar conceptually to .NET IL, Java bytecode etc., things designed for JIT compilation. Yes, and like with Wasm, the engine is responsible for JITting. But giving the user the power to escape the runtime and emit native code and jump to it is dangerous.
- tombl 2y ago
  wasm has no way to remap writable memory as executable, but you can absolutely call back into javascript to instantiate and link a new executable module, like https://github.com/remko/waforth https://github.com/remko/waforth does.
  - bhelx 2y ago
    Yes, I understand that you can do anything with imports. But that's not part of the Wasm spec. That's a capability the host has decided to give the module. Of course the person with the most privilege can always open holes up, but that capability is not there by default.

flohofwoe 2y ago

> Just in Time (JIT) compilation is not possible as dynamic Wasm code generation is not allowed for security reasons. Browsers definitely use a form of JIT-ing for WASM (which is a bit unfortunate, because just as with JITs, you might see slight 'warmup stutter' when running WASM code for the first time - although this has gotten a lot better over the years). ...also I'm pretty sure you can dynamically create a WASM blob in the browser and then dynamically instantiate and run that - not sure if that's possible in other WASM runtimes though, and even in the browser you'll have to reach out Javascript, but that's needed for accessing any sort of 'web API'.

torginus 2y ago
>Browsers definitely use a form of JIT-ing for WASM I (and the article) wasn't referring to this kind of JIT. I was referring to the ability to dynamically create or modify methods or load libraries while the app is running (like `DynamicMethod` in .NET). Afaik WASM even in the browser does not allow modifying the blob after instantiation. The thing you are referring to puzzles me as well. I initially thought that WASM would be analogous to x86 or ARM asm and would be just another architecture emitted by the compiler. Running it in the browser would just involve a quick translation pass to the native architecture (with usually 1-to-1 mapping to machine instructions) and some quick check to see that it doesn't do anything naughty. Instead it's an LLVM IR analog that needs to be fed into a full-fledged compiler backend. I'm sure there are good technical reasons as to why it was designed like this, but as you mentioned, it comes with tangible costc like startup time and runtime complexity.
- flohofwoe 2y ago
  > Afaik WASM even in the browser does not allow modifying the blob after instantiation. ...not your own WASM blob, but you can build a new WASM blob and run that. > The thing you are referring to puzzles me as well... Yes, compilers emit WASM, but that WASM is just a bytecode (similar to JVM or .NET bytecode but even higher level because WASM enforces 'structured control flow') and needs to be compiled to actual machine code on the client before it can run, and this isn't a simple AOT compilation - in browsers at least (it used to be for a while in Firefox, but that caused issues for large projects like Unity games, which might take dozens of seconds to AOT compile). AFAIK all browsers now use a tiered approach. The WASM-to-machine-code compilation doesn't happen on the whole WASM blob at once, but function by function. For the first time a WASM function is called, a fast compilation will happen which may have slow runtime performance, from then on, 'hot functions' will be compiled with a higher tier backend which does additional optimization, is slow to compile but has better runtime performance - and AFAIK this is also quite similar to how Javascript JIT-ing works. Also from what I understand WASM compilation is more complex than just translating bytecode instructions to native instructions. It's more like compiling an AST into machine code - at least if you want any performance out of it. The only difference to JS might be that WASM functions are never 'de-optimized'.

bhelx 2y ago

The statement is correct. Wasm cannot mark memory as executable. It's effectively a Harvard Architecture. The code and memory are split. Furthermore you cannot jump to arbitrary points in code. There isn't even a jump instruction. > I'm quite convinced the alleged security argument is bull. You can hot reload JS (or even do wilder things like codegen) at runtime without compromising security. JIT here is referring to compiling native code at runtime and executing it. This would be a huge security compromise in the browser or in a wasm sandbox. > I don't see any technical reason why this couldn't be possible. If this were a security measure, it could be trivially bypassed. It's not because it's baked into the design and instruction set. You can read some more about how it works here: https://webassembly.org/docs/security/ https://webassembly.org/docs/security/ > Also, WASM bytecode is very similar conceptually to .NET IL, Java bytecode etc., things designed for JIT compilation. Yes, and like with Wasm, the engine is responsible for JITting. But giving the user the power to escape the runtime and emit native code and jump to it is dangerous.

tombl 2y ago
wasm has no way to remap writable memory as executable, but you can absolutely call back into javascript to instantiate and link a new executable module, like https://github.com/remko/waforth https://github.com/remko/waforth does.
- bhelx 2y ago
  Yes, I understand that you can do anything with imports. But that's not part of the Wasm spec. That's a capability the host has decided to give the module. Of course the person with the most privilege can always open holes up, but that capability is not there by default.