Referencing locations across memories about multi-memory

[tlively]

What do you mean by "referencing memory locations across memories"? Code in general isn't associated with a single memory, so the same function could access multiple memories, for example to transfer data between them.

[penzn]

How to reference "full address" in presence of multiple memories. If we take only the index into memory into account there will have to be different code for different memories. For example a function would work only on memory N and memory M (hardcoded in loads in stores), but not on other memories.

My question is how to reference both indices at once - this way one can write a function that would do the same thing regardless of which memory the pointer came from. The tricky part is that "which memory" is indicated by an immediate, however it might be possibly to build a wrapper around dereferencing since there is a rather limited number of memories, but I am not sure how performant that would be.

For a real-world example see OpenCL generic address space, this can also come up in attempting to implement multi-memory in pure C++ (#31 (comment));

[tlively]

Oh gotcha. There's no way to be polymorphic over memory in the proposal, so a br_table mapping a dynamic index to a static index is the best you can do. It's possible in principle for a producer to synthesize those switches so that the frontend can offer memory polymorphism.

[penzn]

Yeah, that is what I thought. I wonder if there are any further gotchas, for example with pointers to pointers, but that might have additional restrictions w.r.t address spaces in IR anyway.

[Serentty]

I’m curious why the proposal specifically only allows immediate values for to specify the address space. Why complicate the implementation of fat pointers like this?

[tlively]

I’m curious why the proposal specifically only allows immediate values for to specify the address space. Why complicate the implementation of fat pointers like this?

Because the goal of the proposal is to relax the current restrictions on the number of memories a module has to improve the composability of Wasm modules rather than to support any particular source-level feature. Applications that need a dynamic number of memories probably need something more similar to the arrays provided by the GC proposal.

[Serentty]

This introduces a certain barrier, though, no? For example, a module cannot pass a pointer to its internal data to code whose default address space is different, even if that other code is multiple-address-space-aware, unless it knows exactly which module will be passing in the pointer. I get that writing composable components usually implies that components keep access to their internal data somewhat separate with a system of privacy, but this seems to enforce that a bit rigidly.

I have not read about the array system yet, so I will take a look at that.

[titzer]

Another possibility is to use a module that has an imported memory and put the function in that module. Thus the function is parameterized over memory by virtue of the module it's in. You can then instantiate that module multiple times, one for each memory, and export the function from the module. The exported function is effectively a closure, since it closes over its instance. You can then put different functions (with different memories) into a table and then use the dynamic "memory index" as the index into the table.

That's a pretty roundabout way of doing it, admittedly. Another possibility is that we consider a way to have first-class memory handles in the future.

[rossberg]

@Serentty:

I’m curious why the proposal specifically only allows immediate values for to specify the address space. Why complicate the implementation of fat pointers like this?

It's the difference between second-class and first-class memories. Memories (like tables and globals) are second-class in Wasm, i.e., they can only be referenced statically. This proposal does not change that.

First-class memories would be a much more substantial extension. They would require the introduction of a memoryref type (analogous to funcref), e.g., to enable putting memories into suitable tables, where they can be indexed dynamically. It furthermore requires new versions of all memory-related instructions that take a memoryref. That is a reasonable extension that some of us would be interested to see, but it's not a goal of this much more moderate proposal. As @tlively said, the goal of this proposal only is to close a gap in the handling of second-class memories.

[rossberg]

Closing as answered.