1.5.0

Whats Changed

Up to 47% faster execution

This release contains a substantial rewrite of Chasm's execution layer.

Instructions are now flattened during decoding and compiled into a shared program containing predecoded executor functions. The interpreter runs these using a simple instruction pointer, with branches compiled as direct jumps and return and exception continuations stored in activation frames.

This replaces the old design, which executed nested instruction arrays by continually manipulating instruction and label stacks at runtime.

On an Apple M5 Pro using JDK 25, the median CoreMark score increased from 626.995 to 924.137, an improvement of 47.4%.

Across the configured 337-fixture corpus, time spent executing Wasm dropped from 3.734 seconds to 2.272 seconds, a 39.2% reduction. Total corpus time fell from 9.150 seconds to 6.685 seconds, a reduction of 26.9%.

There are also some smaller improvements in this release, including folding local.tee into producer destinations and using optimistic trap-based bounds checking for fused JVM memory stores.

Faster instantiation

Instantiation time across the same corpus dropped from 3.069 seconds to 2.359 seconds, a reduction of 23.1%.

Bytecode fusion is now always enabled, but the wider compiler and runtime changes mean the work performed during instantiation is still considerably faster overall.

For the next release I'm working on a new single-pass compiler, with the aim of bringing compilation and instantiation time down further.

API changes

RuntimeConfig.bytecodeFusion is now deprecated. Bytecode fusion is always enabled and setting this property to false no longer has any effect.

The property has been left in place for compatibility and will be removed in a future major release.

Fixes

Validation is now iterative over the flattened instruction stream. This removes a potential stack overflow when validating modules containing deeply nested instruction blocks.

This release also fixes validation of result types for return_call and return_call_indirect.

Gradle plugin changes

The Chasm Gradle plugins now target Java 17 bytecode, matching the requirements of modern Gradle and Android Gradle Plugin versions.

This only affects the plugins running inside Gradle. Chasm's JVM and Android runtime libraries continue to target Java 11 bytecode.