rdunnington / bytebox Goto Github PK
View Code? Open in Web Editor NEWStandalone WebAssembly VM.
License: MIT License
Standalone WebAssembly VM.
License: MIT License
Adding memory leak detection to the wasm testsuite runner will ensure the vast majority of allocating code gets coverage.
zig build test-cffi
should build a C file that loads a wasm file and invokes a function in it, link it with bytebox.lib
, and run the exe, expecting no errors. This will ensure the FFI code paths remain exercised in CI.
Depends on #2 to avoid writing shell script for each platform.
The current testsuite mirror is using an old version, it should be updated since the newer suite has some extra test cases and fixes for bugs in the tests.
There should be an easy way to examine bytebox performance relative to other wasm engines under various workloads. The current bench program just prints some simple timings, nothing fancy. Ideally we'd have a one-button command to run a more advanced test suite, complete with visualizations to make it easy to see what areas bytebox perf needs to improve.
this would allow applications that require this mode to be ported to wasm, such as htop, MC, alsamixer and others (in fact, 95% of the software uses ncurses doing it).
(i found this in c. termios.h functions: tcsetattr tcgetattr)
A quickly-hacked together powershell script is doing the work here, but only works on windows. A zig program would be portable and could call out to either a checked-in binary or require WABT on the system if one doesn't exist for the OS.
The FFI code should expose an interface to override the builtin logger.
I've been poking around bytebox and this is a solid project. One thing that I would like to add is metering. This is something that wasmtime and wasmer (and probably others) have implemented.
Basic idea is this: you configure your module instance to have a certain amount of "fuel". Then a function is called and the vm either runs to completion, traps, or if the fuel meter reaches zero it traps as OutOfFuel or something similar.
I'd be happy to implement something and contribute it, but I wanted to talk through what type of metering before starting.
The most straight forward would be to have each instruction consume a certain amount of fuel units. Simple ones consume 1 or 2, more complex like call_indirect or select_t might consume more.
It looks like wasmtime just has 1 fuel unit for everything but branches, nop, and drop. https://github.com/bytecodealliance/wasmtime/blob/c477424f45871563be02eba14815ba3446158441/crates/cranelift/src/func_environ.rs#L328-L344.
And wasmer allows you to pass in a custom meter function. https://github.com/wasmerio/wasmer/blob/9573519e225b3ea6bd371c832fd352e72314074e/lib/c-api/src/wasm_c_api/unstable/middlewares/metering.rs#L180
There are perks to both, but I wasn't sure what your design philosophy is more geared toward. Let me know what you think.
As of this writing, wasi-testsuite does not have full coverage of the functions in preview1, and as a result the untested functions have not been implemented. To reach parity with other runtimes, bytebox still needs to implement:
Followup to #37. Need to support the new table64 part of the memory64 spec. Tests have been coming in hot, and it doesn't seem like there's much toolchain or client support at the time of this writing.
To allow for easier integration with other projects, bytebox should provide a C wrapper around the public API. Ideally this is tested with an actual integration in another project, such as wasm4.
Due to the mem64 test needing to use clang to build C code, it's been added as a dependency. You can bypass it with --no clang when running zig build, but ideally we either build with zig (pending a compiler bug fix) or move the clang compile to happen at runtime execution of the test.
Currently the wasi_rights arg is essentially ignored for most wasi calls. To be compliant with the spec, the bytebox wasi runtime should return NOTCAPABLE when functions are called for file descriptors that don't have the particular rights. Special attention should be given to preopen rights and inheriting rights.
Currently the order of args is: bytebox <FILE> [WASM_ARGS]... [OPTION]...
. However, wasmtime (and other runtimes) put their option args before the wasm file like so: wasmtime [OPTION]... <FILE> [WASM_ARGS]...
. Bytebox should match this ordering to make it easier to run as a drop-in replacement, or at the very least to make it easier to compare runtimes.
To do this, in the file run/main.zig
, parseCmdOpts()
will need to be updated to account for the reordering.
Stack-based VMs have inherent performance limitations that are not present in register-based VMs. To reach or surpass performance of other WASM VMs, bytebox will need to implement a register-based VM. To do this, we will need to:
wasm3 allows you to supply a wasm file and invoke a specific function, supplying it with parameteres like so:
wasm3 [options] <file> [args...]
The run exe should do the same, and utilities should be provided to autoconvert string parameters into the proper Val
types the wasm function expects, if possible.
The current implementation of the wasi functions are not threadsafe, as wasi file descriptors are backed by an internal data structure that isn't threadsafe, nor wrapped by any locks. This is fine for simple programs, but more complex programs that embed bytebox may invoke wasm functions from different threads. Ideally the solution will also allow compiling thread safety out if it isn't needed to avoid the overhead in single-threaded environments.
Currently zig build test
runs the wasm test suite, and you have to manually invoke zig test
to run unit tests. Running wasi tests is even more of a pain where you have to manually run a python command. Ideally we have a uniform interface for running all the tests from zig build
:
zig build test
: runs everythingzig build test-unit
: only unit testszig build test-wasm
: only wasm test suitezig build test-wasi
: only wasi test suiteBy convention, init() never returns errors and just initializes the struct. We should follow this convention.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.