0.9.41

Bugfix

• Modules with large amounts of recursive types should now have a small memory footprint

Full Changelog: 0.9.4...0.9.41

0.9.4

Breaking API Changes

Chasm now exposes a small part of its internal runtime to the public api. All Values and ValueTypes given to chasm now use the same types chasm uses internally to operate on .

The reasoning behind this change is largely performance related, the boxing and unboxing of the internal types to the public api type was prohibitively expensive, particularly when dealing with host functions. This would cause a ton of temporary allocations and GC pressure.

Whilst exposing these internals isn't ideal I don't plan for chasm to be used directly by the majority of consumers. In the coming months I will add a plugin that code gens a kotlin interface from wasm modules, this plugin will generate a pure kotlin api and hide almost all of chasms api. Allowing the core library to make breaking changes whilst the plugin stays stable.

More performance

Last release focused on the interpreter dispatch loop, this release focuses on optimising some core instructions and also the entry and exit routines of chasm.

Calling chasm on a function with a single noop instruction is a great way to understand the cost of entry and exit which I have created a benchmark around here.

Running this on a Pixel 8

0.9.3: 20 micros
0.9.4: 3 micros

I believe its possible to get this sub 1 microsecond by shifting more work to the in the instantiation phase however theres lots of other work elsewhere which would have a more meaningful impact for now.

No threads execution phase

For a bunch of different reasons I've had to switch focus and really work on performance, threads will land before 1.0 but right now theres a lot of work to do in order to make chasm go fast with all types of workloads.

API calls for releasing resources

• DropStore (Use this 99% of the time)
• DropInstance

These calls manually drop all of the associated state allocated and close any resources. This is particularly relevant on native platforms as the memory implementation calls rust over ffi and thus is unable to track when kotlin objects are GC'd. Failing to call this will result in mmap'd regions of memory active and reduce the global address space until your process exits.

Known Issues

There is a known issue of excessive memory consumption for modules with a large amount of types, in some cases this may OOM. This is an issue created by the algorithm that unrolls recursive types introduced in the Wasm GC proposal. 0.9.3 exacerbated this problem by calling this process more times than was necessary, 0.9.4 removes that issue but the underlying algorithm remains troublesome and needs to be optimised. Which leads onto the next release

Next release

• Bytecode fusion
• GC instruction predecoding
• Recursive Type algorithm optimisation

0.9.3

What's Changed

Performance

Chasms performance changes drastically with this release as I've began to optimise the interpreter. As such the time taken for chasm to complete the official wasm testsuite has dropped from 8 minutes to 6 seconds on the jvm with similar speedups on other platforms.

Threads proposal decode and validation

Chasm can now decode and validate wasm modules with bytecode from the threads proposal, execution support will come in the next release

Host Function Exceptions

Host functions can now throw a HostFunctionException, this will be caught internally by the VM and chasm error will be returned.

Windows support dropped for now

This will be readded before chasms 1.0 but its exclusion for now allows development to progress faster

New Contributors

• @renovate made their first contribution in #36

Full Changelog: 0.9.2...0.9.3

0.9.2

What's Changed

• Automation of the GC proposal testsuite
• Simplified GC approach
• 100% passing of all testsuite tests for all semantic phases of every proposal
• Module Information API
• Tags API
• Tons of bugfixes

Full Changelog: 0.9.1...0.9.2

0.9.1

What's Changed

• Update testsuite to latest by @CharlieTap in #26
• Wabt 1.0.36 by @CharlieTap in #27
• Migration from wabt to wasm-tools by @CharlieTap in #28
• Exception Handling Proposal by @CharlieTap in #29

Full Changelog: 0.9.0...0.9.1

0.9.0

What's Changed

• Kotlin 2.0.20 by @CharlieTap in #23
• Public API and Imports/Host Function DSL by @CharlieTap in #25

Breaking Changes

This version begins the stabilisation of a public api for chasm and hide its internals from downstream consumers. For this reason a layer of indirection has been introduced and all necessary public types are duplicated in chasm's public module.

A short summary of changes and basic migration guide are as follows:

• Creation of a store is now only possible using the factory method (previously you could call construct on the runtimes own store):

// The type will now be io.github.charlietap.chasm.embedding.shapes.Store
val store = store()

• Classes referenced in the chasms ast and runtime modules should now use the corresponding classes of the same name in the package io.github.charlietap.chasm.embedding.shapes.*

For example

// function
io.github.charlietap.chasm.embedding.shapes.Function

⚠️ There is one exception and that is the ModuleInstance is now known as io.github.charlietap.chasm.embedding.shapes.Instance

Other changes

There is also an experimental DSL builder api for defining imports and host functions, for now this will be undocumented as it may change as we develop a WASI layer on top of it. But as a sneak peak...

fun WasiPreview1(store: Store, memory: Memory) = imports(store) {
    function {
        moduleName = "wasi_preview_"
        entityName = "fd_write"
        type = functionType {
            params { i32() }
            results { i32() }
        }
        reference(fdWrite(memory))
    }
}

Full Changelog: 0.7.1...0.9.0

0.7.1

What's Changed

• Gradle 8.9 by @CharlieTap in #19
• Multiple Memories Proposal Support by @CharlieTap in #21

Full Changelog: 0.7.0...0.7.1

0.7.0

What's Changed

• WABT 1.0.35 by @CharlieTap in #9
• Kotlin 2.0.0 by @CharlieTap in #11
• Fix x87 Float Rounding Issues by @CharlieTap in #12
• Wasm testsuite traps by @CharlieTap in #13
• Wasm testsuite malformations by @CharlieTap in #14
• Gradle 8.8 by @CharlieTap in #15
• Wasm testsuite exhaustion by @CharlieTap in #16
• Wasm testsuite linking by @CharlieTap in #17
• Wasm testsuite validation by @CharlieTap in #18

Notes

Chasm is now passing the entire wasm testsuite 🥳

There is also a new api for validating wasm modules, its designed to be chainable alongside the existing functions

 module(reader)
 .flatMap { module ->
    validate(module)
 }

Full Changelog: 0.6.1...0.7.0

0.6.1

What's Changed

• Replace recursive executors by @CharlieTap in #10

Full Changelog: 0.6.0...0.6.1

0.6.0

What's Changed

• Wasm Test Suite Integration by @CharlieTap in #7
• Optimisation of bulk memory operations to use a single operation rather than the recursive byte by byte impls from the spec
• Rework of control flow to use a state machine implementation
• All the bugfixes

Full Changelog: 0.2.2...0.6.0