Serialize a compiled module

[clarkmcc]

Describe the solution you'd like
Is it possible to replicate this feature from wasmer-go? Compiling a module results in a significant number of allocations, so I'd like to compile a batch of modules ahead of time to reduce the runtime memory overhead.

[codefromthecrypt]

I guess what we are really talking about here is externalizing the compilation cache. plus possibly some guard to make sure if the structure of the code changes the cache is invalidated.

		codes           map[wasm.ModuleID][]*code // guarded by mutex.

I think we can look into this after SIMD is done, wdyt @mathetake?

PS, related, but not exactly the same as this: #179

[F21]

I think this will also help us improve mjml-go performance: https://github.com/Boostport/mjml-go#benchmarks

Currently, spinning up a new worker using InstantiateModule() is quite expensive, so if we can clone a module, it would drive a lot of performance improvements.

[codefromthecrypt]

@F21 I think you already have an issues about InstantiateModule() #602 which is unrelated to this because Compile happens before that. Just setting expectations.

[F21]

Oops, I must have misread. This feature would still potentially be useful for us. We're currently shipping a .wasm compressed with brotli, which is decompressed and compiled in init(). If the file size from serializing a compiled module is acceptable, we can just ship that directly in our library and remove the .wasm completely.

[mathetake]

Note that this comes with severe security concerns -- as this means that we allow users to directly execute any native code without validation passes (which are applied during wazero.CompileBinary). That means we also should provide some ways to do binary signing or something like that E.g. https://github.com/wasm-signatures/design

Regardless, I will work on this after finishing SIMD instructions (== completion of Wasm 2.0 Draft). Stay tuned!

[codefromthecrypt]

thanks for the feedback folks, this is great. don't worry too much about issue classification as we can sort it out.

[mathetake]

I think all is set to implement the externalization of compiled native code...

[mathetake]

one thing we have to figure out is that how to do the version/invalidation; if the internal of the compilers change, the compiled module won't work with the latest version of wazero. Therefore, we have to know if the compiled module binary's version (version of compiling wazero) matches the one of running wazero's version. Maybe embedding commit hash into the global variable helps in general if wazero is the executable (via Go's linker flag), but this time wazero is library.

[codefromthecrypt]

ack we need to look at existing VMs and how they do bytecode validation and to what degree this applies to us. Especially we shouldn't commit to a serialization mechanic prior to aug-31 which is our first beta, but that doesn't prevent experimentation before that.

[clarkmcc]

@mathetake the challenge with the commit hash approach is that it will change, requiring re-serialization even if the compiler internals did not change. This project is currently pushing several commits a day. Changes to the ARM compiler for example would not need to impact modules compiled for x86 (not sure if that's even a legitimate example, but you get the idea).

Obviously, the harder problem is how do you actually version optimistically. I briefly looked at Wasmer and it looks like they have a dedicated serialization format that is manually adjusted whenever breaking changes are made. See wasmerio/wasmer#2747, CosmWasm/cosmwasm#1223. The downside of this approach is that it requires someone who is involved enough in the project to bump that version if a change to the project would break the serialization format.

The other option (and I don't know what this would actually look like in practice yet) is to hand-craft a wasm module that is able to get as close to 100% test coverage of the underlying interpreter as possible, and then the CI/CD indicates that we need to bump the serialization format if running that module fails.

[codefromthecrypt]

good points, @clarkmcc. I also don't believe a commit hash approach would work unless stable tags are in use (ex monthly tags starting end of august), and even then I think we may end up needing something more fine tuned than that

I plan to add some research here as well as the problem isn't unlike other tools with compilation cache regardless of webassembly. I'll also have a look at the links you mentioned while takeshi is out.