OCaml's Bigarray module can't handle large linear memory sizes

[sunfishcode]

memory.ml is currently using OCaml's Bigarray module, specifically Bigarray.Array1, to represent linear memory.

Bigarray's interfaces all use OCaml's int type for array extents and index values. While int has a host-dependent size, it is 31 bits on some common systems. It is also signed, so it can only hold values less than 1<<30.

Consequently, on 32-bit hosts, it seems the WebAssembly reference interpreter is limited to linear memory sizes less than 1 GiB, even when the underlying host is capable of allocating that much memory.

Am I understanding everything here correctly? And if so, are there any alternatives to Bigarray which allow for bigger sizes?

[sunfishcode]

One more note: I noticed this while working on wasm's integer operator semantics, and noticed that address_of_value currently does Int32.to_int i, which silently wraps if the value is outside the OCaml int range, which is not the intended semantics.

[rossberg]

I think you're correct. This is a limitation on 32-bit systems. I suggest defining `address` and `size` to be `nativeint`. Then `address_of_value` would no longer wrap. Furthermore, the `create` function then needs to check whether the size overflows an int, and if so, raise `Out_of_memory`. That way, sizes too large are not observably different from OOM, which seems like suitable behaviour. Analogously, load & store functions in memory.ml need to check whether the index overflows int range and raise `Bounds` in that case.

[lukewagner]

I consider this basically resolved by #108 which at least confines the hand waving to one well-commented block.