Add WasmVm::serialize method to get serialized AOT compiled module#543
Add WasmVm::serialize method to get serialized AOT compiled module#543leonm1 wants to merge 8 commits into
WasmVm::serialize method to get serialized AOT compiled module#543Conversation
Co-Authored-By: Rachel Green <rachgreen@google.com> Signed-off-by: Matt Leon <mattleon@google.com>
WAMR does not support serialization: https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/doc/wasm_c_api.md#unsupported-list. Signed-off-by: Matt Leon <mattleon@google.com>
leonm1
requested review from
PiotrSikora,
martijneken and
mpwarres
as code owners
Signed-off-by: Matt Leon <mattleon@google.com>
| TestWasm wasm(std::move(vm_)); | ||
|
|
||
| std::chrono::time_point<std::chrono::system_clock> unprecompiled_load_start = | ||
| std::chrono::system_clock::now(); |
| EXPECT_LT((precompiled_load_end - precompiled_load_start) * 2, | ||
| (unprecompiled_load_end - unprecompiled_load_start)); |
There was a problem hiding this comment.
I suspect that 2x is not a large enough multiplier here in terms of expected improvements, but I don't have an actual data to back this up. Could you print the numbers from a local test runs?
Also, I think it would be good to have an upper limit in tests for precompiled option to catch serious degradations is load times.
See: TestVm::Init test for similar checks.
There was a problem hiding this comment.
I also expect this to be closer to 4x improvement for V8 and 300x improvement for wasmtime; however, when running with --runs_per_test=1000, I found that 2x was enough to eliminate flakes, even in exceptional cases.
I'm not quite sure about how upper limits will translate to tests -- since the CI runs on shared github runners and, for s390x, on a virtualized environment on said shared runner.
If it provides any relief, Google has automated benchmark regression testing for the speed of loading modules into proxy-wasm-cpp-host on a specialized cluster for benchmarking. However, I don't see those benchmarks ever covering beyond V8 and wasmtime.
| // Wasmtime sticks | ||
| std::string_view Wasmtime::getPrecompiledSectionName() { return "precompiled_wasmtime_bytecode"; } |
There was a problem hiding this comment.
Since we're providing a serialize() interface now, do we expect the precompilation to happen using this function in a proxy-wasm-cpp-host based tool, or using the engine's native tooling? (Ideal answer would be: former with a fallback to latter)
Notably, it looks that the native tools always use a single hardcoded section, which means that you can only include a single precompiled variant for each engine version in Wasm module, which makes this problematic across data plane version upgrades.
What we did for V8 is that V8::getPrecompiledSectionName() contains V8 version number and platform, and it can embed precompiled versions for multiple V8 engines and platforms in a single Wasm module.
There was a problem hiding this comment.
I expect any user doing AOT compilation will embed proxy-wasm-cpp-host as the interface to interact with the wasm runtime, since our precompiled section name is effectively bespoke to our implementation. If someone wants to create a tool (such as Envoy's wee8_compile), that's fine by me, as long as they can conform to the section name.
I now understand the meaning behind the V8 precompilation section name! I have made the wasmtime precompiled section name match.
Signed-off-by: Matt Leon <mattleon@google.com>
Signed-off-by: Matt Leon <mattleon@google.com>
Signed-off-by: Matt Leon <mattleon@google.com>
Signed-off-by: Matt Leon <mattleon@google.com>
2 participants
This PR contains both serialization and deserialization since we had no testing surface for deserialization, as pointed out in https://github.com/proxy-wasm/proxy-wasm-cpp-host/pull/522/changes#r2921882220.
This implements serialization and deserialization for wasmtime and V8.