Stream: wasmtime

Topic: wasmtime on the JVM

nikomatsakis (Jun 23 2024 at 20:38):

Hi folks,

I'm curious to run WASM+WASI on the JVM. So far I've found the following options

• Graal
• the wasmtime-java project, which looks like more experimental than production ready
• dylibso/chicory which has a WASM interpreter and supports WASI (perhaps extended with something like the cretz/asmble project, which can convert wasm to jvm bytecode; I see they have that listed as future work)

Of these, embedded wasmtime into the JVM via FFI seems like the most promising to get results in the shortterm across a wide range of virtual machines, but the 1st and 3rd are pretty interesting longer term options. Does anyone know of any other bindings to wasmtime from Java?

Ralph (Jun 24 2024 at 11:38):

the kotlin peepz have made I think the most progress in javaland.....

nikomatsakis (Jun 24 2024 at 11:39):

links?

Ralph (Jun 24 2024 at 11:42):

https://github.com/Kotlin/kotlin-wasm-examples

Ralph (Jun 24 2024 at 11:42):

a wide spectrum of examples

Ralph (Jun 24 2024 at 11:42):

it would of course depend on what you really want to do, obvs

nikomatsakis (Jun 24 2024 at 11:42):

thanks!

Lann Martin (Jun 24 2024 at 12:49):

I'm pretty sure that is "Kotlin targeting Wasm", not "Kotlin targeting JVM that works on Wasm"

Lann Martin (Jun 24 2024 at 12:50):

@Joel Dice may have something to say about Wasm on JVM

Joel Dice (Jun 24 2024 at 14:09):

@nikomatsakis I've done some research and work on transpiling JVM bytecode to Wasm/WASI (e.g. TeaVM-WASI), but it sounds like you're interested in hosting Wasm+WASI in a JVM, which is orthogonal. I don't have much experience with that, so you probably already know more than I do, but I agree that JNI (the JVM's FFI mechanism) is likely your best bet.

The main issue with that approach is that not all of Wasmtime's public API is exposed as part of its C bindings. Specifically, WASIp2 is based on the Component Model, and last time I checked little or none of Wasmtime's CM API is available via C. That's partly because the statically-typed, high performance Rust API relies pretty heavily on proc macros and generics, so it's not clear how to translate that into C, although there's also a dynamic (though somewhat less efficient) API that would be easier to translate.

Improvements to the Wasmtime C bindings would enable not only more complete JVM bindings, but also wasmtime-py, wasmtime-go, etc., so they would be most welcome.

Ralph (Jun 24 2024 at 15:36):

Lann Martin said:

I'm pretty sure that is "Kotlin targeting Wasm", not "Kotlin targeting JVM that works on Wasm"

ooops, you're right!

Edoardo Vacchi (Jun 24 2024 at 15:38):

@nikomatsakis the team is advancing pretty quickly wrt AoT support on Chicory! https://github.com/dylibso/chicory/pull/395

Edoardo Vacchi (Jun 24 2024 at 17:11):

obviously, avoiding FFI has the usual benefits of playing nicely with the JVM runtime (e.g. wrt JVM's threading/GC etc). If you want to chat with the team you can join their Zulip too https://chicory.zulipchat.com

nikomatsakis (Jun 24 2024 at 17:46):

@Edoardo Vacchi super cool!

nikomatsakis (Jun 24 2024 at 17:47):

I'd love to chat about chicory but I need an invite for the zulip

Edoardo Vacchi (Jun 24 2024 at 18:29):

I forgot you need an invite, there you go https://chicory.zulipchat.com/join/g4gqsxoys6orfxlrk6hn4cyp/ @nikomatsakis

Last updated: Nov 26 2024 at 00:12 UTC