feat: port memory packing from wizer

[andreiltd]

This patch shamelessly copies wizer memory packing implementation and adapt it to use waffle types. I've tested this with StarlingMonkey and it produces ~30% smaller components. The weval StarlingMonkey testsuite passes as well.

For reference implementation see: https://github.com/bytecodealliance/wasmtime/blob/8adf03d4557acaa8384ec084946614d3f87c39ff/crates/wizer/src/snapshot.rs#L120

[cfallin]

Thanks a bunch for this! The improvement stats are impressive...

Would you mind adding an attribution somewhere near the top of the algorithm ("Segment-merging logic and associated tests borrowed from Wizer; see https://github.com/..." or similar)? Totally fine to do this license-wise but want to make sure we give credit.

Separately, it's too bad we can't factor this to a single implementation somewhere shared by both tools. I'll cc @fitzgen here -- what would you think about the wasmtime-wizer crate exporting an API that (maybe generic over traits?) can take a list of memory segments and the data they refer to, and provide the final merged list? It would certainly be an odd corner of the API alongside the high-level wizening interface, but it would genuinely be useful for other Wasm producers, too. Or maybe we move the whole algorithm to a utility API in wasm-encoder or something...

[cfallin]

Can we add a comment here that this is also load-bearing for multimemory handling? Below we rely on segments being sorted by memory as the most-significant field (so all segments for one memory are together).

[andreiltd]

Thanks for review! Yeah, code duplication is unfortunate. I don't have a good instinct where the shared code could live but I'm happy to work on PR(s) that move it.

[fitzgen]

Separately, it's too bad we can't factor this to a single implementation somewhere shared by both tools. I'll cc @fitzgen here -- what would you think about the wasmtime-wizer crate exporting an API that (maybe generic over traits?) can take a list of memory segments and the data they refer to, and provide the final merged list? It would certainly be an odd corner of the API alongside the high-level wizening interface, but it would genuinely be useful for other Wasm producers, too. Or maybe we move the whole algorithm to a utility API in wasm-encoder or something...

This code is in kind of a weird spot where there doesn't really seem to be a natural place to deduplicate it to IMO but is just big enough that deduplicating it would be nice.

I guess we could move it to wasm-encoder? Would need a rayon cargo feature tho to turn the parallelism on and off at compile time, which is kind of annoying.

Also probably not the end of the world to duplicate it...

[cfallin]

OK, cool, let's merge this for now, and we can figure out if we want to de-duplicate it in followup work...