wasm

Joel Martin 2025-01-22T15:04:56.317849Z

I suspect that the first place that this will be addressed will be in the "Use linear memory as a scratch space" category. Right now the bulk memory standard doesn't cover GC arrays (bulk memory landed well before GC). But extending the bulk memory operations so that you can copy from a GC array to/from linear memory would make linear memory a more performant scratch space (bulk copy is up to 20x faster). Those ops seem pretty straight forwards (just have to make sure they interact with GC sweeps) and wouldn't impact sandboxing posture (you can already do this byte/word at a time). Being able to share GC object between the host (JS) context and the wasm context would be much nicer from a developer perspective (especially for Clojure on wasm) but for the specific probably dthompson describes above, I think it could be addressed fairly quickly.

john 2025-01-22T16:42:32.935049Z

I feel like we could do gc better with the immutable assumption. But I guess you have to a) interact with js from wasm anyway, and b) interact with other guest langs through this new gc standard anyway. So even if there was a path for native gc, you'd lose a lot by not using the standard, right?

john 2025-01-22T16:46:03.533359Z

And maybe some more efficient "better GC for immutable langs" doesn't matter for us since we're not pure

john 2025-01-22T16:49:14.447859Z

Seems like carp lang is part of the way there. Automating some of the borrow checker method using scope