Hot swap (hot reload) of running WebAssembly module

[qouteall]

Hot swapping makes development iteration easier (especially in game development), even if it can only hot-swap function body.

The spec doesn't seem have the API for hotswapping code for a running WebAssembly module. It allows reading the memory, but not the stack frame and local variables.

There are workarounds such as using a custom interpreter, but a custom interpreter is too slow. Another possible workaround is to make every function call use a function pointer in the table, then hotwrapping updates that function pointer, which also hurts performance.

It would be beneficial that WebAssembly provides API of updating function in a running WebAssembly module. Or more generally, provide ways of getting stackframes of a running WASM module, and initiating a new module with specified memory and stackframes.

[tlively]

The implementation of such a feature would have the same performance problems as the function pointer approach you mentioned, since the engine would have to do a similar indirection under the covers. Also, it seems like it would be extremely difficult to map the old module's stack frames onto the new module's functions if those functions were changed at all. Overall this seems like something that would be better implemented by specific toolchains or frameworks, which can reason more about the intent of the changes and how to map the old module to the new module, rather than as part of the core Wasm spec or the JS API spec.

[rossberg]

Making this a requirement on the spec level would put a lot of costly constraints on implementations. Stack layout in particular would need to be exposed and made much more rigid and stable than engines typically have it.

And then the engine isn't even the tricky part in enabling hot code update. To be serious about it, you essentially need to lock down the entire tool chain for producing the code: the compilers, their runtime system, libraries, possibly other codegen tool, none of them must ever change in interesting ways, because even the tiniest change in memory or stack layout will break backwards compatibility with memory images for code updates. This is extremely at odds with how most languages implementations evolve in practice.

Likewise, you may need to lock down user code as well. Even just adding, say, a single (unused) global can potentially change the memory layout and addresses assumed by the compiled code and hence be incompatible with a pre-existing memory image, at least in conventional compilation approaches. Unless the compiler puts in various indirections for keeping these dimensions extensible in place.

In short, supporting hot code update completely changes the way engines, languages, libraries, applications need to be implemented, and invalidates many techniques, optimisations, and life cycle processes typically used.

Hence, like @tlively, I think this can at best be a feature of individual implementations, not something a standard like Wasm can reasonably prescribe.

Edit: The problem is essentially equivalent to that of "orthogonal persistence" with code upgrade. Mark Miller aptly described the problem with that in a short chapter.

[qouteall]

Thanks for the explanations.