Memory size tiers

[ghost]

One basic approach to supporting a negotiated initial memory size as discussed in #331 would be to allow the wasm code to declare a range to memory size tiers. The lowest tier would be the minimum memory size, and the runtime would not run the code if this minimum could not be allocated. If the runtime has more memory then it could allocate more memory using the tiers a guidance. The intention is that the runtime would choose a size of one of the tiers, rounding up a little if it suits the implementation.

Some code has a variable memory requirement, but not fine grained or linear, and these tiers can capture these requirements and avoid overallocation by keeping the allocated memory size close to the requested tiers. It is an incremental step forward from just a low and high memory requirement specification.

When an application is using pointer masking the tiers will be powers of two plus a small guard area.

This is a very simplistic specification that could be subsumed by more general approaches.

[ghost]

To allow compile time customization of the code based on these tiers, each tier could define constants that would be updated in the literal pool, and referenced efficiently from there using existing opcodes. Having constants for each tier avoids specing how they can be computed from the memory size.

One set of constants might also represent 'no compile-time memory size', and when present the runtime can choose not to specify a memory size at compile time but would use this set of constants. This would suit an application that makes use of pointer-masking only for performance reasons, but works fine without, and the constants would likely be a mask of -1 etc that the compiler could optimize away.

The constants would be optional and the runtime could still use the tiers to choose an initial memory size available at runtime.

These could be implemented in asm.js by global constants or expanded to inline literals.

Again this could be subsumed by more general support.