[HN Gopher] Just-in-time code generation within WebAssembly
       ___________________________________________________________________
        
       Just-in-time code generation within WebAssembly
        
       Author : nickmain
       Score  : 83 points
       Date   : 2022-08-18 16:01 UTC (6 hours ago)
        
 (HTM) web link (wingolog.org)
 (TXT) w3m dump (wingolog.org)
        
       | kristiandupont wrote:
       | I experimented with this for native x86 many years ago
       | (https://github.com/kristiandupont/rtasm). I used it to generate
       | BitBlt functions with no conditionals in the hot paths, which
       | created noticeable performance improvements with no compromise in
       | flexibility. Debugging code like that is painful though!
        
         | nerpderp82 wrote:
         | Afaik, the windows graphics libraries used to do something
         | similar.
        
       | UncleEntity wrote:
       | A lot of the stuff they're doing with wasm is confusing to me.
       | Compiling an interpreter to wasm to run a script in the browser
       | seems, IDK, a bit much.
       | 
       | I'm not seeing how using the first Futamura projection (targeting
       | wasm) wouldn't both result in a significantly smaller module size
       | and give more opportunity to optimize/specialize the code as it
       | could perform offline analysis. One could even use the second
       | Futamura projection along with the dynamic code loading from TFA
       | and get an online jit compiler virtually for free.
       | 
       | If I was getting paid megabucks to do these types of things
       | that's where I'd spend my research time.
        
       | yuri91 wrote:
       | This is a nice overview on how to achieve just-in-time
       | compilation in Wasm, and the demo is pretty cool. Good work!
       | 
       | We use similar techniques to power Webvm[1], an X86 Virtual
       | Machine that runs linux programs in the browser.
       | 
       | A proper Wasm JIT API in JavaScript would be even better of
       | course, but as the article says, cool things are already possible
       | right now.
       | 
       | I expect to see more projects doing Wasm just-in-time compilation
       | in the future (I believe that V86[2] also already does it)
       | 
       | [1]: https://webvm.io/
       | 
       | [2]: https://github.com/copy/v86
        
         | nerpderp82 wrote:
         | I haven't read the article yet, but you can pass the emitted
         | Wasm back to the top level JS and have it instantiate a new
         | module, potentially using the same heap.
         | 
         | A Wasm trampoline-continuation.
         | 
         | I assume this is what v86 does.
        
           | yuri91 wrote:
           | By "Wasm JIT API in JavaScript" I mean a native way for the
           | browser to support the JIT use-case.
           | 
           | Generating entire modules works, but it has a number of
           | issues.
           | 
           | For example, you need to carefully decide how big your
           | modules are going to be:
           | 
           | - Too small, and you end up compiling many many modules,
           | which eventually crashes the browser if you don't dispose of
           | the old ones
           | 
           | - Too big (many functions batched together), and you have too
           | much latency before your code is available to run
           | 
           | Being able to compile a single function to add to an existing
           | module (or something like that) would help a lot.
        
       ___________________________________________________________________
       (page generated 2022-08-18 23:00 UTC)