Hola :wave: Chasm went to 2.0 this week. This rele...
# webassembly
c
Hola 👋 Chasm went to 2.0 this week. This release was more about setting us up for the future than anything else with some breaking changes that I've been wanting to make for some time now, in short it comes with: • A new Android target (min SDK 28) • JVM target is now minimum JDK 17 • A redesigned Host Function API • The deprecated
macosX64
and
iosX64
targets have been removed • The Gradle plugin no longer supports AGP 8 • Changes to plugin generated implementations as they are now private by default and constructed through top level factory functions • Previously deprecated APIs and configuration options have been removed, including producer mode and
RuntimeConfig.bytecodeFusion
As always theres some performance uplift, roughly 20% execution speed across all targets with Android being more like 30%. github.com/CharlieTap/chasm/…/2.0.0
🚀 12
K 10
❤️ 5
e
out of curiosity, why minSdk 28? that excludes ~5% of users
c
I want to leave the door open to move Android to SharedMemory without making a breaking change. Theres nothing currently tying Chasm to 28 and I've actually realised SharedMemory is 27 so we should be able to drop it at least one. I've found that ART is missing some intrinsics which make working with anything other than a ByteArray expensive. I'm hoping (maybe wishfully) that if I file them as bugs they'll get them looked at
^^ There's two problems in the above, general access is slow for non atomic reads and writes and atomic access through VarHandle is shockingly bad. None of these issues exist when lowering with HotSpot
e
ah. what about
sun.misc.Unsafe
speeds? newer R8 rewrites some usages of VarHandle to that, and while I don't think that optimization applies to these cases, it may make a difference. https://android-developers.googleblog.com/2026/07/how-r8-made-kotlin-coroutines-2x-faster.html
ah, not VarHandle, but Atomic*FieldUpdater.
c
Thank you for the steer I'll look into this 👍