Stream: general

Topic: Zero copy (mmap) data streams between components


view this post on Zulip Christof Petig (Aug 17 2025 at 12:16):

Starting from my AUTOSAR experiments I finally have a webassembly prototype for zero copy publisher subscriber. It uses WASI 0.3 streams to broadcast host side shared memory buffers (a resource) from one publisher to two subscribers. The components pre-allocate linear memory (size calculated by the host to enable page aligned padding) for memory mapping the data into their linear address space.

Prototype for zero-copy shared memory inter-component exchange - cpetig/wasm-shm-test

view this post on Zulip Christof Petig (Aug 17 2025 at 12:17):

The buffer API could be implemented with copying without the guests noticing, also several efficient zero-copy mappings to MPU only embedded are possible. The host can optimize the implementation to avoid attachment during run-time without affecting the ownership logic, this of course assumes a well-behaved publisher; subscribers remain untrusted. Adding a subscriber only requires creating another stream<memory-block> on the sender side (and writing four bytes to it per published data). So the overhead per subscriber is minimal.

In a point to point communication the subscriber receives ownership of resources sent by the publisher.
For shared buffers the writer passes the ownership to the buffer, subscribers won't touch it (can only read-only borrow access), the writer destructs the previous objects when the buffer is re-attached for overwriting.

Note: I abuse dummy resource handles to represent linear addresses, as these scale to 64 bit on native.

view this post on Zulip Christof Petig (Aug 17 2025 at 12:19):

The idea is to extend this prototype towards a caller provided buffer prototype of the component model.

Last week, an idea was presented by which callers could prevent unnecessary intermediate copies using the syntax: read: func(length: u64) -> result<list<u8; ..length>,error-code>; Is there any prov...

view this post on Zulip Jacob Lifshay (Aug 17 2025 at 15:02):

one thing to consider is that wasm is not only 32-bit, so the size should be 64-bit where 32-bit components require the size to be small enough to fit

view this post on Zulip Christof Petig (Aug 17 2025 at 15:13):

I would vote for resource handles (id not rep) to become 64 bit on wasm64, just for consistency. But this has not yet been specified.

In my case I use WIT to describe future built-in functions, so this isn't a shortcoming of the technology but rather a temporary workaround.

view this post on Zulip Christof Petig (Aug 17 2025 at 15:14):

Sorry, I misread your post. For a single shared memory block 4GB sounds plenty to me, even in the context of machine vision or learning.

view this post on Zulip Christof Petig (Aug 17 2025 at 15:16):

Sadly up to now there is no pointer sized data type in the component model, this is why I use resource handles which have this property in symmetric ABI.

view this post on Zulip Jacob Lifshay (Aug 17 2025 at 15:18):

well, I'd expect 3D medical images could easily be >4GB if you have a 32-bit color at each voxel and have > 1024x1024x1024 resolution

view this post on Zulip Jacob Lifshay (Aug 17 2025 at 15:20):

there's probably lots of other things where an item can reasonably be more than 4GB, and having a 64-bit size isn't much burden on 32-bit instances

view this post on Zulip Jacob Lifshay (Aug 17 2025 at 15:23):

plus, in 10-20yr, 4GB will probably be pitifully small


Last updated: Dec 06 2025 at 05:03 UTC