Compilation of JavaScript to WASM, Part 3: Partial Evaluation

This article is the final installment of a three-part series by Chris Fallin, focusing on the compilation of JavaScript to WebAssembly (Wasm) with an emphasis on partial evaluation. The previous posts introduced a portable interpreter and discussed ahead-of-time (AOT) compilation. This post delves into the construction of AOT compiler backends, specifically addressing the challenges of compiling JavaScript bytecode to Wasm. The author critiques the direct porting of SpiderMonkey's JIT to Wasm due to operational and security constraints, such as the prohibition of runtime code generation in Wasm environments. Instead, Fallin proposes leveraging a portable interpreter (PBL) that maintains the semantics of JavaScript execution, allowing for easier debugging and development. The article introduces the concept of the first Futamura projection, which combines an interpreter with its input to derive a compiled program. This technique involves constant propagation and specialization, where the interpreter's behavior is simplified based on known constants. However, the complexity increases with the introduction of loops and multiple opcodes, necessitating advanced dataflow analysis techniques to ensure accurate compilation. The author emphasizes the importance of developing robust tooling to facilitate this process and improve debugging capabilities for Wasm bytecode.

- The article concludes a series on compiling JavaScript to WebAssembly, focusing on partial evaluation.

- It critiques direct JIT porting to Wasm due to operational and security limitations.

- The author proposes using a portable interpreter to maintain execution semantics for easier debugging.

- The first Futamura projection is introduced as a method to derive compiled programs from interpreters.

- The complexity of constant propagation and dataflow analysis is highlighted in the context of loops and multiple opcodes.