## 7 Prospective Aspects of WebAssembly
### Multiple Memories  
Developers are aiming to extend the capabilities of Wasm in the future by allowing the use of multiple memories within a single module. While it is currently possible to create multiple memories in a Wasm application, each memory is isolated within its own module, and a module or function cannot access multiple memories simultaneously. This limitation prevents efficient data transfer between memories, as it requires individual function calls into different modules for each value. The motivation behind supporting multiple memories in a single module is driven by several use case scenarios. First, for security purposes, a module may want to separate public memory which is shared with the outside from private memory that is encapsulated within the module. By isolating these memories, data exchange can be controlled and managed effectively. Second, even within a single module it is beneficial to have separate memories for shared memory used by multiple threads and memory used in a single-threaded manner. This isolation ensures better memory management and avoids potential conflicts or data corruption. Another use case is the need for persistence. An application may want to preserve certain memory states between runs by storing them in a file. However, not all memory needs to be persistent, and separating memories allows for greater flexibility in managing memory lifetimes. This proposal addresses the issue of linking multiple Wasm modules into one. Many tools exist that can merge multiple modules through static linking. However, if the modules define more than one memory, this merging process becomes challenging. Allowing multiple memories in a single module resolves this limitation and enables seamless merging of modules. Additionally, the ability to use multiple memories is crucial for scaling purposes. With the current 32-bit memory address space limitation, applications requiring more than 4 GB of memory face efficiency challenges. Multiple memories provide an efficient workaround until 64-bit memories become available. Furthermore, the proposal supports polyfilling, which emulates certain features such as garbage collection or interface types in existing Wasm. The ability to add auxiliary memories distinct from the module's address space facilitates the implementation of these features within the current Wasm infrastructure. The design of this extension aligns with the original Wasm design and introduces minimal changes. It allows for multiple memory imports and definitions in a single module, adds memory index parameters to memory-related instructions, and extends validation and execution semantics accordingly. The binary and text formats are updated to accommodate these changes. Implementations of Wasm engines already handle multiple memories, although code within a module has been limited to accessing a single memory. Reserving a register for the base address of the main memory has been a common technique. With multiple memories, engines may require an extra level of indirection to access the desired memory. In summary, this proposal enhances the capabilities of Wasm by enabling the use of multiple memories within a single module. It addresses various use case scenarios, improves memory management, facilitates data exchange, and aligns with the existing design of Wasm. By allowing the explicit definition and access of multiple memories, Wasm becomes more flexible and versatile in its memory handling capabilities.