3 ms·

> If the title is true, that would be a huge achievement. Fundamentally it's "just" a JIT that compiles to WASM. It's a ton of effort to build something like t

> If the title is true, that would be a huge achievement. Fundamentally it's "just" a JIT that compiles to WASM. It's a ton of effort to build something like that, but I think fundamentally it's not an impossible undertaking. The JIT seems to be living there, so you can probably explore from there: https://github.com/copy/v86/blob/master/src/rust/jit.rs https://github.com/copy/v86/blob/master/src/rust/jit.rs WRT speed advantage: compared to what?

whizzter 5y ago
I'm not entirely sure that the browser runtimes are suited for this since I watched a friend demo-ing V86 and the amount of crashes with modern OSs just seemed to make it a toy (though I might be proven wrong). One plausible guess I have is that they might be running out of memory since the browser runtimes are expecting the WASM code to be long lived whilst a emulator JIT by nature should be able to adapt to rapidly changing code and blows out of memory before things are cleaned up.
- the_mitsuhiko 5y ago
  Presumably the crashes are happening because the instruction set implemented by the JIT is on Pentium II level and so encountering modern X86 instructions makes it fail. I am not familiar with the linked project but there is no real reason why you could not emulate a 32bit Intel perfectly in WASM. For 64bit I'm not sure if wasm64 wouldn't be required.
  - londons_explore 5y ago
    I think there are browser-level crashes too because you're using the WASM JIT-compiler in ways it hasn't been thoroughly tested for. The Chromium team is pretty receptive to patches though, so for a big project like this it doesn't seem unreasonable to just patch the browser to perform well enough for your use case, and then upstream the patch so everyone has it within a few months when you're ready to launch your product.
    - the_mitsuhiko 5y ago
      I have done a lot with wasm and I can't say I ran into browser level crashes.
s-macke 5y ago
It is definitely not "just" a JIT compiler. For example, you can't just copy QEMU's JIT solution and hope that it works. So I'm interested in your solution. For example, do you compile each code block (from jump to jump instruction) into a separate WebAssembly module? If yes, then I wonder how many millions of small WebAssembly modules a browser can handle, how well the foreign function interface between JavaScript and WebAssembly actually performs and how much of the time the Browser JIT spends in compiling your generated code. How do you handle machine code manipulation during execution for example? How do you mark already compiled memory pages as dirty. I will definitely look at your code :-) > WRT speed advantage: compared to what? The speed advantage between interpreted and JIT compiled execution.
- the_mitsuhiko 5y ago
  I just want to clarify that this is not my code. I just happened to remember this project from a while back.

whizzter 5y ago

I'm not entirely sure that the browser runtimes are suited for this since I watched a friend demo-ing V86 and the amount of crashes with modern OSs just seemed to make it a toy (though I might be proven wrong). One plausible guess I have is that they might be running out of memory since the browser runtimes are expecting the WASM code to be long lived whilst a emulator JIT by nature should be able to adapt to rapidly changing code and blows out of memory before things are cleaned up.

the_mitsuhiko 5y ago
Presumably the crashes are happening because the instruction set implemented by the JIT is on Pentium II level and so encountering modern X86 instructions makes it fail. I am not familiar with the linked project but there is no real reason why you could not emulate a 32bit Intel perfectly in WASM. For 64bit I'm not sure if wasm64 wouldn't be required.
- londons_explore 5y ago
  I think there are browser-level crashes too because you're using the WASM JIT-compiler in ways it hasn't been thoroughly tested for. The Chromium team is pretty receptive to patches though, so for a big project like this it doesn't seem unreasonable to just patch the browser to perform well enough for your use case, and then upstream the patch so everyone has it within a few months when you're ready to launch your product.
  - the_mitsuhiko 5y ago
    I have done a lot with wasm and I can't say I ran into browser level crashes.

s-macke 5y ago

It is definitely not "just" a JIT compiler. For example, you can't just copy QEMU's JIT solution and hope that it works. So I'm interested in your solution. For example, do you compile each code block (from jump to jump instruction) into a separate WebAssembly module? If yes, then I wonder how many millions of small WebAssembly modules a browser can handle, how well the foreign function interface between JavaScript and WebAssembly actually performs and how much of the time the Browser JIT spends in compiling your generated code. How do you handle machine code manipulation during execution for example? How do you mark already compiled memory pages as dirty. I will definitely look at your code :-) > WRT speed advantage: compared to what? The speed advantage between interpreted and JIT compiled execution.

the_mitsuhiko 5y ago
I just want to clarify that this is not my code. I just happened to remember this project from a while back.