Overview of WASI support in Chicory
mainwasip1 specification (WASI version 0.1), which provides a virtual system interface with POSIX-like syscalls. This allows WebAssembly modules to interact with system resources in a standardized way.repository·main·Indexed 22 days ago
https://github.com/dylibso/chicoryA pure-Java WebAssembly runtime designed to run Wasm modules on the JVM without native dependencies or JNI. Chicory prioritizes safety, simplicity, and portability over maximum execution speed, providing full support for the core WebAssembly specification and WASI (wasip1). The project includes tools for differential fuzz testing using wasm-smith, JMH performance benchmarks, and support for running instrumentation tests on Android (API 33+).
wasip1 specification (WASI version 0.1), which provides a virtual system interface with POSIX-like syscalls. This allows WebAssembly modules to interact with system resources in a standardized way.Chicory is a JVM-native WebAssembly (Wasm) runtime. Unlike runtimes written in C, C++, or Rust (such as v8, wasmtime, or wasmer), Chicory is written purely in Java. This allows you to run WebAssembly programs with zero native dependencies or JNI, making it highly portable across any environment that supports a JVM.
Chicory 1.0.0-M2 introduces several technical improvements to WebAssembly compatibility:
Chicory is currently evolving with several key focus areas for future development:
-experimental modules by fixing bugs, removing limitations, and stabilizing APIs.Lumis4J leverages several technologies to provide a robust developer experience:
A host function is a Java function provided to a Wasm module to fulfill one of its imports. Because host functions run in the JVM, they are unrestricted and can perform any operation (like file I/O or network calls), effectively allowing the Wasm module to "escape the sandbox."
Security Warning: Host functions act as a security boundary. If the Wasm code is untrusted, implement host functions carefully to prevent unauthorized access to the host environment.
To define a HostFunction, you must provide:
console and log).Instance object, which provides access to the Wasm module's linear memory.import com.dylibso.chicory.runtime.Instance;
import com.dylibso.chicory.runtime.HostFunction;
import com.dylibso.chicory.wasm.types.ValType;
import com.dylibso.chicory.wasm.types.FunctionType;
import java.util.List;
var func = new HostFunction(
"console",
"log",
FunctionType.of(
List.of(ValType.I32, ValType.I32), // Arguments: length and offset
List.of() // Return type: void
),
(Instance instance, long... args) -> {
var len = (int) args[0];
var offset = (int) args[1];
// Use instance.memory() to read data from the Wasm module's linear memory
var message = instance.memory().readString(offset, len);
System.out.println(message);
return null;
});When working with a Store, keep the following behaviors and limitations in mind:
store.instantiate("name", module) is a shorthand for retrieving current import values, building an instance with those values, and registering it. It is the recommended way to instantiate modules."logger2" with a function logIt will overwrite any existing logger2.logIt.Store is a mutable object and is not thread-safe. It is not intended to be shared across threads.Store does not automatically resolve interdependencies between modules. If your modules depend on each other, you must instantiate and register them in the correct order.Chicory provides several experimental modules for advanced use cases. These are released with the -experimental suffix and reside in the experimental namespace. They are not yet considered fully stable:
aot-experimental: An Ahead Of Time (AoT) translator that converts Wasm to Java Bytecode. It is very fast but requires reflection and depends on ASM.aot-maven-plugin-experimental: A Maven plugin that uses the AoT translator at compile time to generate artifacts on disk, avoiding runtime reflection and external dependencies (though it sacrifices dynamic loading).cli-experimental: A Command Line Interface for evaluating Chicory directly from the terminal.host-module-annotations-experimental & host-module-processor-experimental: A pair of annotations and an annotation processor designed to help integrate Chicory via a higher-level, Java-idiomatic generated API.Chicory is designed with specific trade-offs in mind to prioritize safety and ease of use over raw performance.
In the context of Chicory and WebAssembly (Wasm):
Wasm modules interact with the outside world through imports and exports. While a module can export functions to be called by the host, it must import functions to perform I/O or interact with other modules. Without imports, a Wasm module is limited to "pure compute" and cannot perform any I/O.
Chicory is a pure Java WebAssembly runtime composed of several key modules that serve different purposes in the Wasm lifecycle:
wasm: The core module providing idiomatic Java APIs for working with arbitrary binary WebAssembly modules and handling the Wasm specification.runtime: The main interpreter. It supports the full V1 WASM specification (excluding SIMD). It is designed to be extremely reliable, portable, and readable.wasi: Provides an implementation of Wasi Preview 1, allowing Chicory to run real-world Wasm modules compiled from languages like Go, Rust, and C++.log: Decouples logging from the Java Platform Logging (JEP 264), which is useful for environments like Android where JEP 264 is unavailable.wabt: A bundled pure Java version of the WebAssembly Binary Toolkit (including wat2wasm and wast2json) provided as a Jar artifact.bom: A Bill of Materials module used to manage dependency versions across the other modules.