Onyx News - Onyx's Custom Runtime

As Onyx targets WebAssembly (WASM) exclusively, running code outside of the browser requires a WASM embedder. The job of the embedder is to translate the WASM Virtual Instruction Set Architecture into a "real" architecture that can be executed on the host system. There are many great WASM embedders that exist for running WASM outside the browser. Here's a small, non-comprehensive list:

All of these embedders are great in their own way, but the one thing they are not great at is providing a great developer experience for Onyx. For this reason, Onyx maintains support for two WASM embedders: Wasmer and OVM-Wasm. Wasmer is used as the faster, production-ready embedder, while OVM-Wasm is used as the development embedder.

OVM-Wasm stands for Onyx Virtual Machine for WASM. The Onyx Virtual Machine (OVM) started as a separate project with the goal of providing a separate compile-target for Onyx; however, to reduce complexity, OVM-Wasm was created as a wrapper around OVM, that provides a wasm-c-api compatible interface, making it a WASM embedder. Since OVM-Wasm is entirely specific to Onyx and can be easily modified to suit the needs of developing Onyx. It has more features compared to a normal WASM embedder, such a debugging interface that is compatible with the Debug Adapter Protocol.

Currently, it does not run as fast as it could. This is due to several reasons, but largely because it compiles WebAssembly down to an interpreted instruction stream, not machine-native instructions. This was done to make OVM-Wasm more portable, but does come at a significant performance cost. To compound onto this fact, the instruction stream itself is not optimized at all. It is the most literal, WASM to OVM conversion possible. This helps the initial startup time be faster, but does incur wasted performance. It is on the (rather large) list of to-dos to add simple optimizations to the embedding process to make OVM-Wasm not as slow.