Regarding the integration of Wasmtime into the off...

# webassembly

[crowforkotlin]

Regarding the integration of Wasmtime into the official Kotlin repository, I have some feedback and reference to share. According to official announcements, Kotlin 2.4.20-RC3 now supports Wasmtime. Below are the issues I encountered when integrating Wasmtime into the Wasmline project.

[crowforkotlin]

First, in a Kotlin/Wasm project, simply using @WasmImport or @WasmExport causes the generated Wasm binary size to bloat from a few KB to around 100–200 KB. (The official implementation has recently optimized this part.)

If the project subsequently uses Wasmtime's JIT to compile the Kotlin/Wasm module, runtime memory consumption increases dramatically. This happens because Wasmtime's Cranelift compiler performs an extensive amount of optimization and analysis. This high memory footprint was the primary reason I eventually abandoned JIT in Wasmline.

For example, when attempting to load a 700 KB Kotlin-generated Wasm module on Android using Wasmtime's JIT, memory usage surged to approximately 1 GB, ultimately triggering an Out Of Memory (OOM) crash.

Because of this issue, AOT compilation becomes necessary to avoid high memory overhead. However, AOT requires the Wasm module to be compiled ahead of time for a specific platform, architecture, and Wasmtime version, generating a precompiled Wasm binary (referred to here as a .cwasm file).

This approach introduces a Wasmtime versioning issue: upgrading Wasmtime may render .cwasm files compiled with older versions incompatible.

Fundamentally, both issues stem from Cranelift. I recently investigated Wasmtime's Winch compiler, but it currently lacks support for certain features required by Kotlin/Wasm, making it unusable for this purpose at present.

Personally, I wonder whether integrating an interpreter specifically designed for Kotlin/Wasm directly into Kotlin might be a more suitable approach.

[crowforkotlin]

Another case involves the AOT approach: precompiling a 700 KB Kotlin/Wasm file results in a .cwasm binary of around 5 MB.

[crowforkotlin]

Another approach is to use an interpreter developed in Kotlin Native, which is bridged through JNI on the JVM platform.

[Jim Teichgräber]

Hi there, thanks for your feedback :)

First, in a Kotlin/Wasm project, simply using @WasmImport or @WasmExport causes the generated Wasm binary size to bloat from a few KB to around 100–200 KB.

I can't reproduce that. Both with 2.4.0, and 2.4.20-RC3, I get about 60 Bytes of size difference between

fun imexported(){
    println("imexported")
}

and

@WasmExport
fun imexported(){
    println("imexported")
}

The rest of the module is a few misc. tiny functions and a main. Also note that by the nature of WASI preview 1, any program that uses at least a println (or anything else that needs interaction with the environment) will already @WasmImport some WASI preview 1 functions implicitly.

(see attached pictures)

A size degradation from a few KB to hundred would definitely warrant an issue in our tracker, so if you can reproduce this failure and report it, that would be hugely appreciated :).



I can't really help with the Wasmtime/Cranelift issues. However, personally, I don't think that implementing a Wasm interpreter is in the scope of the Kotlin/Wasm project. There are many runtimes out there, and while we may not explicitly support all of them, any that support the Wasm extensions we need, should be able to run our modules (with WASI preview 2 / component model support, this will unfortunately narrow down as not as many runtimes support the CM).
For running on Android, Chasm may also be a good fit (cc @Igor Yakovlev who has experimented with running K/Wasm programs inside Chasm iirc).

A thought on the side: if Winch doesn't support certain features required by Kotlin/Wasm, then in my view the easiest approach, that still allows taking advantage of the rest of the Wasmtime infrastructure, would appear to be extending Winch with support for those features. Other than that, I can only recommend contacting the Wasmtime maintainers and discussing these JIT compilation issues with them.

[crowforkotlin]

Thanks for the clarification.

Regarding the module size issue, I haven't carefully compared the generated artifacts with the latest Kotlin 2.4.0. I remember encountering this kind of size increase with Kotlin 2.3.0, although it may also have been related to the specific code I was using. I'll try to reproduce it and verify whether the issue still exists.

Regarding the Cranelift issue, I was mainly sharing some of the problems I encountered while integrating Wasmtime into Wasmline and discussing some possible approaches. Since the JIT compilation and memory usage are ultimately related to Wasmtime/Cranelift, I agree that this part would be better discussed with the Wasmtime maintainers. I am also planning to do that.

I looked into Winch because, based on my experiments, using Cranelift JIT on Android can result in very high memory consumption. Given that Wasmtime is primarily described around server-side use cases, I'm not sure Cranelift is an ideal fit for mobile scenarios. If Winch supported the Wasm features required by Kotlin/Wasm, it could be an interesting alternative to investigate. Otherwise, AOT seems to be the practical option, although it comes with the trade-offs I mentioned above.

Thanks again for the clarification. I'll try to reproduce the size issue and continue investigating the runtime side.