Conversation
|
Back in the day we did think this would make sense eventually, but meanwhile JSPI provides what Asyncify does but in the VM itself, which is a lot more efficient. That support of course includes reference-typed locals. It sounds like you might be using Asyncify in some other way? Can you explain the motivation and how important this is for you? |
|
Hi!!! I was planning to use this for Saikuro's executor abstraction ( The main issue I ran into is that reference-typed values can remain live across suspension points (which is often the case in Saikuro). In those cases Asyncify currently aborts, which makes it impossible to transform otherwise-valid modules. |
Maybe not yet, but should be very soon, as quickly as vendors push out browser updates? (Safari 27 was the last major browser to add this, and was recently released). Overall this is not a simple change, so I wonder if it makes sense to land or not, given it will be obsolete shortly. |
|
That's fair! The main reason I'm trying to get reference spilling working in Asyncify is that Saikuro is meant to run across a variety of environments (Wasmtime/Wasmer for standalone, embedded WebViews, etc.) where JSPI is often not supported. Without it, the only alternative currently implemented to suspend execution in Wasm is a busy-poll spin loop. But because Wasm holds the CPU while spinning, futures waiting on host events/JS promises can't resolve and end up timing out/deadlocking, which is... not ideal. |
|
I see now, then it is for non-Web places... yes, wasm stack switching is still a way off, and it is what is needed there. In that case maybe this makes sense to land. Let me read the code some more. |
| type, | ||
| asyncifyMemory)); | ||
| offset += size; | ||
| if (type.isRef()) { |
There was a problem hiding this comment.
Places like this are getting quite verbose with the two different code paths now, ref and non-ref. How about moving this into a helper function?
| type, | ||
| asyncifyMemory)); | ||
| offset += size; | ||
| if (type.isRef()) { |
Fixes #3739.
Right now
wasm-opt --asyncifyaborts if a reference-typed value is live across an unwind. Asyncify spills locals into a linear-memory stack, and references can't be stored there, so it gives up.This was annoying for my IPC/RPC runtime, Saikuro, so I decided to go fix Asyncify.
As discussed by @kripken, @martianboy, and @surma in #3739, the fix is to spill references into tables instead of linear memory.
The Asyncify ABI/API remains unchanged, so this shouldn't impact users beyond fixing reference-type support, I believe.
Asyncify still only supports one active pause at a time, though. As a result,
asyncify_start_unwindnow traps if it sees a nonzero cursor.However, multi-pause support would need per-pause regions in the tables. As pointed out, that's a separate problem and a much bigger change, so I left it out of this PR.
Note: This is essentially a cleaned-up and "productionized" version of the proof-of-concept @alexdoesh posted in #3739.