Data padding

[penzn]

Padding can be used implicitly or explicitly with other approaches. With implicit padding, the memory is padded behind the scenes, while it looks contiguous from Wasm app's point of view. With explicit padding we would provide an API to either pad Wasm memory or set up the pointers for the user to pad it.

There are some caveats from Wasm point of view with both of these. Implicit padding would have to be inserted at the point of a vector store, which is tricky since the module memory is a contiguous array of bytes from both Wasm and JavaScript point of view, hence every padded store to a new location would necessitate adjusting the mapping of all further indices and shifting the memory after it. Also, there might not be a good way to make this seamless in JavaScript.

Some explicit padding would be possible to do in this proposal already, as the length is known. One challenge is doing it from JS - it does not have access to Wasm instructions, only to exports, though the compiler can expose that as an exported symbol. And the second challenge is adding this to data segments, since indices in those are supposed to be module constants.

Aside on Wasm memory - modules have the ability to grow memory, but they have to do their own memory management, which would only be concerned with Wasm indices, instead of actual pointers.

[lemaitre]

Implicit padding would have to be inserted at the point of a vector store, which is tricky since the module memory is a contiguous array of bytes from both Wasm and JavaScript point of view, hence every padded store to a new location would necessitate adjusting the mapping of all further indices and shifting the memory after it. Also, there might not be a good way to make this seamless in JavaScript.

I don't know much about the memory model of WASM and how mappings work, but that looks super complicated.
Runtime would need to track every single "padding store" and adjust the memory mapping on-the-fly.
Moreover, you don't know in advance to which memory location a store is performed, hence the on-the-fly adjustments.

Some explicit padding would be possible to do in this proposal already, as the length is known. One challenge is doing it from JS - it does not have access to Wasm instructions, only to exports, though the compiler can expose that as an exported symbol.

I see 2 ways of doing that:

• functions to round up/down an integer to a multiple of the actual alignment
• runtime constant containing the actual alignment

As far as I understand, both solutions can be exported to JS, and with those, it is simple to pad arrays from JS.

I think this round up/down is enough and we don't actually need a "padded and aligned memory allocation" per se. It could just be built on top of this round up/down.

And the second challenge is adding this to data segments, since indices in those are supposed to be module constants.

I don't quite get this one.
Is this about static arrays?
If yes, maybe we can solve this with a relocation phase where actual address materialization is postponed until the module is loaded.
To make it simpler, you could probably do that only for padded static arrays (that would need to be located after the rest of the static data), and have fixed location pointers to refer to those arrays.
Like that, only those pointers need to be adjusted.

If your concern was not about static arrays, then I think there is no problem because it is all dynamic memory allocation and thus, dynamic size.
The fact that the dynamic size will be different depending on the architecture does not matter much, I guess.

[penzn]

And the second challenge is adding this to data segments, since indices in those are supposed to be module constants.

I don't quite get this one.
Is this about static arrays?

Yes it is about static arrays - Wasm supports them via initializer sections, where everything needs to be a constant known at module instantiation. Now that I think about it again, vector length should be known at instantiation time, we might be actually fine...