memory.grow's price may not reasonable

[zzfire]

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.

[zzfire]

Initial Cost
The Initial cost for instantation for the module is calculated from all the sections other than the code section (which is metered at runtime). This information is stored as a custom section that is inserted directly after the preamble. It uses the the name initCost and its payload contains the initial cost encoded as an unsigned leb128 interger.

besides, another question, above description in README seems not implemented in current project. Is there a customized clang&llvm tool chain to insert the initial cost value in the custom section, where can I find it? and in wasm-metering, we have to read the initial cost value from custom section, currently it's missing.

thanks