andreaTP (Apr 16 2026 at 11:08): andreaTP (Apr 16 2026 at 11:08):Yesterday I finally announced what I was working on since some time:
https://github.com/roastedroot/chicory-redline
Under the cover we are translating Chicory IR to Cranelift IR and generating ASM, performance are, as expected, fully comparable to wasmtime.
andreaTP (Apr 16 2026 at 13:49):forgot the link to the blog post: https://chicory.dev/blog/chicory-redline/ :sweat_smile:
Chris Fallin (Apr 16 2026 at 15:27):this is super-cool! and I love the integration work with Cranelift running as a .wasm itself so you have no native code blobs to ship with your JAR. Very very slick
andreaTP (Apr 16 2026 at 16:10):One minor friction point I found is that trap lowers to ud2/udf, but it's the JVM that handles signals, so it crashes the entire process.
At the moment we avoid using it by emitting bounds checks etc. that catch the condition earlier.
Would it be a viable change to make trap lowering configurable (e.g., call a configurable function instead)?
Chris Fallin (Apr 16 2026 at 16:12):I suppose you could generate a call instruction instead of a trap instruction? (You're doing the Wasm-to-CLIF translation yourself? Or are you borrowing wasmtime's code for this?) This is more or less what we do when signals-based traps are disabled in Wasmtime
andreaTP (Apr 16 2026 at 16:20):yes I'm doing the Wasm-to-CLIF translation, but have to manually handle every single trap site, with trap lowering configurable, any missed site would safely call an handler
fitzgen (he/him) (Apr 16 2026 at 16:23):see https://github.com/bytecodealliance/wasmtime/blob/main/crates/cranelift/src/trap.rs where we change the CLIF instructions we are translating wasm traps to based on whether we can rely on signal handlers / virtual memory or not
andreaTP (Apr 16 2026 at 16:23):nothing major though, if this is the expected usage I'm fine with it :slight_smile:
fitzgen (he/him) (Apr 16 2026 at 16:23):you would need to just do the same thing
Last updated: May 03 2026 at 22:13 UTC