Recently Oracle opened its WebAssembly engine, GraalWasm, implemented in GraalVM, the development team explained that GraalWasm currently implements the WebAssembly MVP (Minimum Viable Product) specification and can run We in a binary format The bAssembly program, which is generated by a compiler back end such as Emscripten.
WebAssembly support extends the ability of GraalVM to execute with other supported languages, further making it a common programming language execution platform. But GraalWasm is still a very early implementation and is in experimental mode.
To achieve GraalWasm, the development team used GraalVM as a platform to provide an effective local evaluation engine, and the Truffle API of GraalVM first implemented the WebAssembly binaries interpreter.
WebAssembly’s semi-structured format makes it easy to restore the program’s control flow structure, allowing the memory data structure of the stored code to be represented as AST. The interpreter sexplanatoryser for programs represented by AST can be written in a very simple way, but while AST-based data structures are easier to check and manipulate, they do have the disadvantage of introducing additional memory overhead.
Bitcode-based code, on the other hand, means that tree nodes are not required to instantiate for each basic instruction, which is why bitcode-based GraalVM interpreters often have a smaller memory footprint.
Because each WebAssembly block contains only a linear sequence of instructions, GraalWasm is able to combine the best approach in two interpreter methods: AST superimposed on the control flow instructions of WebAssembly, such as if and loop. But each block uses a Truffle AST node, called a Wasm block node, which reduces memory footprint because a single instruction in each block does not require a separate node object.
In addition, the GraalWasm block node does not copy parts of the original instruction flow, but simply includes pointers in an array of bytes for the WebAssembly binary.
Correspondence between text WebAssembly, binary WebAssembly, and GraalWasm AST
The interpreter implemented on top of this data structure is a mixture between an AST-based interpreter and a bit code-based interpreter. At a higher control flow level, it is distributed between the appropriate base blocks. In each base block, the interpreter is completed within the interpretation loop of the operating code that iterates the base block. This design makes translation easier to understand and simplifies some evaluation.
At runtime, the interpreter and program are passed to Truffle’s local evaluation engine, which then dedicates the interpreter to the program and passes the specialized code to the GraalVM compiler, eventually generating efficient assembly code for the target platform.
More technical details about GraalWasm can be found on the official blog:
The development team also described the project’s next development plan, which stated that one of GraalWasm’s motivations was to extend the set of APIs supported by the node.js implementation of GraalVM, and that the increase in WebAssembly support would enable it to implement the V8 and Load edgy WebAssembly binaries. APIs features.
The next step will be to implement the WebAssembly System Interface (WASI), which is necessary to run the WebAssembly program outside the Web context. WASI is a set of APIs that abstract access to various operating system features, such as file APIs, network sockets, and clocks.
At the same time, GraalWasm will focus on improving performance, and initial experiments and performance adjustments to multiple C microbenchmarks show that GraalWasm currently achieves peak performance of approximately 0.5 to 0.75 times compared to local GCC binaries compiled at the highest optimization level.
On the other hand, improve the debugging support in GraalWasm and integrate it with the rest of the GraalVM.