just realized that the WASM page size, 64 kbytes, perfectly matches the 8086 segment size, so you could use segment registers to index into the WASM linear memory
10
1
101
Conversation
Replying to
Eew. 64k pages are awful for allocation granularity, but I guess this goes with multi-GB web/Electron apps where folks just don't care...
1
1
Replying to
do you actually understand how wasm works or do you just talk shit about it because you presume you do
1
3
Replying to
Didn't mean this as talking shit about wasm just the web ecosystem. I think it was an unfortunate choice wasm made that I just discovered from your tweet.
1
2
Replying to
so, wasm uses a linear memory and the "page size" is solely the granularity of its size, which means that you'll never lose more than 64k
this does matter for wasm on microcontrollers (which seems like a marginal use case to me anyway) but not elsewhere
2
3
Right, it’s not meant directly for most allocators because it’s linear, you only add more from your current heap base like sbrk. Most programs are expected to have their own allocator on top. But if you’re happy with sbrk then great! There’s also plans for larger pages…
3
1
Yeah, brk model is kinda backwards though. Can't individually return memory, among other things. My new allocator for musl, OpenBSD malloc, and various others don't use it. But either way usage jumps in page size increments.
1
I'm not sure we have the same usage models in mind. A program can, before starting, specify "I'll start with MIN memory, and grow up to MAX". You can set MIN==MAX, never grow, and allocate within the range you have. Or you can start small and grow with sbrk.
1
I believe musl is quite popular as a libc on wasm, and is in the MIN==MAX category. The VM will give you virtual memory, zero-filled lazily on first access. You can ask for 4GiB if you want (the maximum since current wasm is 32-bit only).
1
When every allocation within a page has been freed, can the memory be returned to the OS? That's why smaller granularity reduces memory usage beyond just the smallest increment size. Larger pages are much harder to clear out to be able to release memory that was used before.
3
1
So for example, maybe for a while the program is using a lot of 64 byte allocations but shifts heavily away from that for other portions of what it does. You're left with a bunch of pages with some 64 byte allocations holding onto them. Smaller pages mean freeing up more memory.
Also really want a large address space to avoid the issue of running out of memory due to address space fragmentation. Virtual memory + large address space means not needing to care much about anything but spans of pages. Smaller pages really do reduce memory usage substantially.
1
1
If the address space is small, you also need to be concerned a lot with address space fragmentation, and it becomes harder to make large allocations over time. Makes it even more important to release memory to the OS sooner so it can do a better job of avoiding the fragmentation.
1
1
Show replies