Hello! A quick update on <chasm> the experimental ...

# webassembly

[Charlie Tapping]

Hello! A quick update on chasm the experimental webassembly runtime I have a been building. Things have been pretty chaotic but we’ve made massive strides forward, highlights include:
• Full decoding/execution support of the wasm 2.0 specification (excluding the execution VectorInstructions)
• Tail call proposal support
• Extended const expressions proposal support
• Typed function references proposal support
• An embeddings api for creation of globals, tables, memories, host functions etc
I’ve also pushed an artifact and updated the README with some primitive instructions so people can begin play around with the library and report bugs.

Next steps:

• GC proposal support (so we can run languages inside of it without them having to compile their GCs to wasm)
• Full validation support of the wasm specification (currently you could pass incorrect programs and they may be accepted)
• Incorporation of the wasm test suite (currently integration tests are limited and bespoke)

[Robert Jaros]

It would be fascinating to see your project support Kotlin/Wasm target as well 🙂 An "inception" 😉

[Robert Jaros]

Why doesn't it support Kotlin/Wasm or Kotlin/Js? It seems to be 100% common code.

[Charlie Tapping]

Tbh the answer is I’m not sure what would happen right now without GC proposal support as the compiler will want to emit heap types that come from that proposal and the runtime will not understand them. I don’t think theres a way to compile kotlin to wasm and have the kotlin runtime bundled in the binary and have heap hypes emulated on linear memory. Maybe @bashor knows more?

[Charlie Tapping]

It’s already kind of inception when its running on the jvm as we’re basically sticking a stack machine into a stack machine

[Darryl Miles]

Is there not a GC shim around that can at least implement GC requirements (for runtimes that do not have the proposal or correct version of proposal available) even if the resulting runtime is not efficient/optimal ?

[Charlie Tapping]

So what typically happens is the languages runtime and GC are compiled to wasm and then run as part of the module, this is how the C# guys got Blazor to work originally. But Kotlins wasm compiler targets wasm GC with the intention of not bundling a GC as it bloats the binary output

[Darryl Miles]

Sure but is there no generic shim (not necessarily developed by Kotlin) that implement the GC specification and export symbols compatible with the specification on WASM runtimes that do not provide it.
This way everyone has access to the specification, even if not efficient

[Robert Jaros]

I think my question about K/Wasm support was misunderstood. I wasn't asking about running K/Wasm compiled code. I was asking why your multiplatform project doesn't support K/Wasm or K/Js targets. It supports jvm and different native targets, but it's all written in common code. Shouldn't adding missing targets "just work"?

[Charlie Tapping]

@Darryl Miles It would be very difficult to create something like that given the nature of how webassembly works intrinsically

[Charlie Tapping]

@Robert Jaros I could add the targets for wasm but it doesn’t really make sense right now, as the kotlin compiler will output those targets with wasm gc features. You could of course run that inside another wasm runtime which supports wasm gc. But it would mean you’re running a less capable runtime (mine) inside a more capable runtime 😅

[Robert Jaros]

You never know when your project will become more capable than others 🙂

[bashor]

I don’t think theres a way to compile kotlin to wasm and have the kotlin runtime bundled in the binary and have heap hypes emulated on linear memory.

I’m not aware about any solution so far 🤷‍♂️

[bashor]

Another project aimed to run wasm inside JVM https://github.com/dylibso/chicory, though pure Java.

[Darryl Miles]

@Charlie Tapping You mean because of the memory isolation between WASM blobs ? that GC is more intrinsic way of managing memory allocation that is internal to a single isolated instance ? But that "shim" can still be WASM linked and merged (ahead of time) at some level with the WASM object/binary code needing GC support, against the expected GC imported symbols (rewriting a new WASM exe). So the deployed result is a single WASM blob that include the application and the GC support and runs with runtime what does-not have GC support.