Charge for table growing

[Stebalien]

We don't curently charge for table growing, but we should. According to the wasmtime docs, each table element requires one usize of memory (host memory).

Proposal: Charge 8 bytes per table element.

1. Instrument and charge for zeroing in wasm.
2. Account for the expanded table memory in wasm.

[aakoshh]

Just looking at where this could be implemented.

When an instance is allocated by the pooling allocator, it already gets the maximum number of table elements writeable to it. The table will be static; it will start from the minimum and account for growth, but this for a static table is just a formality of checking the limits.

I'm not sure at the moment how to figure out the minimum table size for the module. Wasmtime doesn't expose the memory plans, and I resorted to calling inst.get_memory("memory"), which was an established well known name. I don't see us using inst.get_table at the moment. The instance limits only allow 1 table per module by default, so I'm assuming this is the function table (because all elements in it have to have the same type). Does that have some well-known name? (EDIT: Found it: the linker allows only "table").

Something I don't understand is that in wasmtime we can see table grow code being translated, but when I follow how we instrument memory growth, there is no such thing as a grow table instruction. At the moment I'm not sure where to inject any charge for growing the table. (EDIT: table.grow shows up as 0xFC proposal here and here. This turns out to be the prefix for bulk instructions, which are here but grow is not something the 0.42.2 version of Parity Wasm recognises.).

I'm also not clear how we'd be using tables in smart contracts. From what I understand they can point at function in the browser for example, they are external functions pointers that wasm cannot manipulate. I'm not sure when they need to grow. But it sounds like we'd have to inject them, which we don't do (or at least I thought bind and import work with a different mechanism). (EDIT: Okay after this example I understand they can be initialised in the module. The docs were a bit cryptic).

So it sounds like we aren't using tables, but we think it could be exploited by the module. Can they use it internally to do actual callbacks? Or could we just limit the number of elements to zero?

[aakoshh]

Okay, based on the findings above it looks like that we can charge for the minimum table size up front, and the contract shouldn't be able to grow it.

[Stebalien]

Status: We now charge for table init, but not for growing.

We now need to charge for growing, but should do this when instrumenting instructions.