WebAssembly.Memory information

[jfbastien]

It seems useful and low-cost to add the following functionality to WebAssembly.Memory:

• initial size
• maximum size
• current (or byteLength to match ArrayBuffer?)

It would also be nice to have similar accessors on WebAssembly.Instance: an Instance's Memory isn't necessarily exported, and therefore isn't accessible. Introspecting its size would still be nice.

Thoughts? Name bikeshed?

[lukewagner]

Adding initial, maximum and byteLength (or just length, to match Table.prototype.length) to Memory makes sense and seems easy.

I'm not so sure about adding properties relating to Memory to Instance. For one thing, it feels like it breaks the encapsulation of the module (if the module chose not to export memory); for another it also wouldn't (easily) generalize to multi-memory.

[jfbastien]

Ah yes, the multi-memory point is spot on! OK, so I'll whip up a PR soon if nobody has any other suggestions.

[kmiller68]

Couldn't we just have each of these properties take a number index for the memory you want? Unless we were going to make them getters, in which case we could return an Array.

[jfbastien]

Couldn't we just have each of these properties take a number index for the memory you want? Unless we were going to make them getters, in which case we could return an Array.

Yeah that sounds good, would be similar to Module.customSections.

I'm not really worried about the encapsulation argument: the memory can't be modified, it can only be queried from this API. We're not breaking the encapsulation of it, we're just acknowledging that there's a memory in there.

[lukewagner]

Hmm, it still doesn't seem right to have Instance be arbitrarily exposing these things but not others and using internal indices; that's... what exports are for.

[jfbastien]

@lukewagner but what if you want to export everything about a memory, but not the memory itself? 🤔

[lukewagner]

Haha, that's a great choice of emoji.

[hvenev]

Actually, I think it would be nice for WebAssembly.Module to provide information about the defined (both exported and not) and imported memories and their initial/maximum sizes. This is helpful if using WebAssembly for a sandbox.

[rossberg]

The JS API type reflection proposal is meant to provide this information in a uniform manner.

This won't allow inspecting private (non-exported) memories of a module, but that is intentional, as the module mechanism is supposed to provide encapsulation.

[hvenev]

Then how would one, for example, limit the total memory used (if there can be more than one memory object)?

[rossberg]

@hvenev, I think that will require different mechanisms anyway. Once we include reference types and managed objects, the size of memories won't tell you much about memory usage anyway.