Shared memory between instances

[axic]

This is related to #17 and #188 / #181 to some extent.

If doing runtime linking, where libraries are spawned as separate instances with their own memory, there is a problem passing data between these instances. The "Wasm threads" proposal (here) contains support for shared memory segments, but finalisation of that is still quite far out in the future.

A simplistic API and approach is presented here, modelled after POSIX's shm subsystem.

• shmemCreate(id: u64, size: u32, ptr: u32, len: u32) - creates a shared memory buffer with size and loads the initial value from ptr ... ptr+len (len can be zero and in that case no ptr can also be "invalid")
• shmemAttach(id: u64, ptr: u32, len: u32) - attaches a shared memory buffer and loads the current value to the memory area pointed by ptr
• shmemDetach(ptr: u32) - detaches the local memory area from any updates
• shmemSize(id: u64) - returns the size of the shared memory

Since no parallel execution exists in "ewasm", whenever a linked module is called, the caller has stopped executing. When a callee is finished, the shared memory areas used are updated prior to returning execution to the caller.

As an example:

currently executing test.wasm:
  ...
  // load memory at 0x1000 with 256 bytes of data
  shmemCreate(1, 256, 0x1000, 256)
  // call `keccak256` in a "linked module"
  keccak256()

currently executing keccak256.wasm:
  shmemAttach(1, 0x20, 256)
  // do the hashing here and eventually copy the result into 0x20 .. 0x20+32

currently executing test.wasm:
  // the memory area 0x1000 .. 0x1000+32 should contain the hash result

[poemm]

Curious, was there a reason for not allowing Ewasm modules to export/import a memory instance between each other? Or modules importing the same memory instance?

Someone may complain about memory copying overhead dominating runtime for some use-cases.