1.0.0

Well... a year and a half later that "side project" is now ready. If you've been following Chasms progress you'll know it's been quite a journey! Thank you to all the people that used Chasm and reached out and gave feedback, if it wasn't for the help it wouldn't have been possible ❤️

Wasm 3.0

The Wasm 3.0 spec is on the cusp of being published and I've spent the last couple of weeks preparing for it. In short it takes a bunch of proposals (FuncRefs, TailCall, GC, Exceptions, Memory64 and more) and merges them into the latest iteration of stable Wasm. Chasm supports all of Wasm 3.0 with the exception of Memory64.

Reasons for not supporting Memory64

Memory64 requires larger pointers, memories and tables , which ultimately result in more overhead , more memory and slower runtime performance. Realistically workloads that require more than 4GB of memory are not well suited for Chasm in its current form and given we're only shipping one artefact its not worth slowing the 99% (32 bit workloads) for the 1%. I have plans for supporting this in the future but thats a long way down the road.

Upgrades to the Gradle plugin

Chasms Gradle Plugin now implicitly wires up the correct chasm runtime depending on the Kotlin plugin and targets configured. This was important as the Plugin depends on the tooling api which ships with the runtime and thus it was possible for a user to previously wire up a version of the runtime which is not compatible with the plugin.

As a result you can now configure whether the runtime is hooked up as an API or IMPLEMENTATION dependency using the Gradle plugin extension:

chasm {
    // default is IMPLEMENTATION
    runtimeDependencyConfiguration = RuntimeDependencyConfiguration.API
}

Similarly chasm now supports configuration of type visibility for the Interface and Implementation its plugin generates:

chasm {
    modules {
        create("TestService") {
            // default is PUBLIC
            interfaceVisibility = TypeVisibility.PUBLIC
            // default is IMPLEMENTATION
            implementationVisibility = TypeVisibility.INTERNAL
        }
    }
}

Unified Versioning

Chasms runtime and Gradle plugin now use the same version (1.0.0), given the plugin now implicitly wires up the runtime it made sense to align them so its easy to understand what version of the runtime is being used.

Stable ABI

For the past year the API for chasm has been in flux whilst I tried to figure out the best way to expose the virtual machine and the metadata associated with it. I'm now happy to say its stable and ready to be used, as a result we're now leveraging the experimental binary compatibility validator that shipped with KGP 2.2.0 to ensure we don't accidentally alter the ABI in unexpected ways between releases of the library.

Removal of the statically linked rust memory library

Last year I swapped out the linear memory implementation for native targets with a statically linked rust library. The intention was to enable efficient atomics for the upcoming threads proposal, unfortunately it doesn't look like the threads proposal is going to make it into the Wasm 3.0 release and it needs a little more time in the oven. Leveraging the native memory implementation has drawbacks in that it needs to be deallocated (technically unmapped), the cognitive overhead this adds to the api is not worth it given we don't support threads yet. For that reason its been removed... and yes we've lost our fancy SIMD string searcher for the time being

Better errors when encountering unsupported Wasm binaries

Previously when executing binaries that feature unsupported instructions the runtime would return a generic InstructionNotFound error. The past couple of weeks I've built support for decoding and validating newer (not yet supported) proposals so we can identify them and return better messaging. For example, given a Wasm binary that features Memory64 instructions, chasm will now return an error 'UnsupportedMemory64Proposal'

Full Changelog: 0.9.81...1.0.0