In webassembly spec, memory.grow has no immediate number parameter, only consume the i32 element in stack top as the page size to grow. Currently in wasm-metering, memory.grow is treated as a "branch" instruction, and charged only by its appeared times, not including its page-size params. I understand it's impossible to get the run-time stack info when statically analysing a wasm file. But is there a more reasonable way to keep the "memory.grow" monster into the cage ?

I have a proposal, if we set the max-size of the memory's page size as a must value and a concrete value(take 1000 for example) before the metering work, is it more reasonable when we only count the appeared times of "memory.grow" ? In detail, in the wasm file's memory section, if max is not set, we set it to 1000, if max is larger than 1000, then failed it as a unqualified contract, if it's smaller than 1000, then we do nothing.