We have preliminary data that suggests stack maps are consuming a large amount (%30-40 of total metadata size) of memory.

Right now our stack maps are just simple bitmaps, so each scales with the size of frame. We also allocate one per call site, and other cases.

I think there's a lot of low hanging fruit here.

Here are a couple ideas of things we could do:

1. call_indirect and call_ref both allocate two identical stackmaps keyed off the two different call sites we generate. We could deduplicate them.
2. Implement hash set based deduplication of stack maps - this will probably slow down our compile time, but by how much?
3. Deduplicate stack maps based on if they just match the previous stack map generated. How well would this perform?
4. Special case stack maps without any references (the extremely common case for linear memory languages) to not have a bitmap
5. Switch from a bitmap to a list of stack offsets that are references - this will beat a bitmap if references are sparse. Also subsumes (4)

I agree, there probably is a lot of low hanging fruit here. Should be relatively easy to improve.

6. Use some kind of run-length coding to compress the individual bitmaps. Instead of just having a sequence of bits, have the bitmap be a sequence of variable length numbers, each number indicating the number of 1 bits or 0 bits that follows next. I think this is an established trick in data compression systems.