additional operator that zeros and allows OS to discard pages?

[lukewagner]

Have we discussed including an op that generates a call to madvise(MADV_DONTNEED)? This was originally considered for the MVP and bumped to Post-MVP. To summarize, such an op would be equivalent to mem.clearing with the fill byte 0, but the op comes with a hint from the program that the pages won't be used for a while and so the backing physical pages should be reclaimed by the OS (re-filling them from the zero-page-pool the next time they are accessed since they are well-defined to be zero).

Two use cases are:

• malloc implementations call madvise(DONTNEED) to release unused physical pages while keeping the virtual address mapping. Given the absence of memory shrinking, this would be the only way for wasm to release physical pages
• apps that want to reuse Memory objects for many sequential short-lived instances but still want to efficiently clear out memory between instances

The natural implementation on POSIX would be madvise(MADV_DONTNEED). On Windows, the same can be achieved by VirtualFree(MEM_DECOMMIT);VirtualAlloc(MEM_COMMIT) although, with shared memory, this requires signal handler support to suppress spurious faults in another thread.

[titzer]

I generally like this proposal, since there is a fallback implementation to simply zeroing the memory (which, however, may be concurrently observable).

Note on the Windows implementation: would also be possible to implement this with a safepoint protocol (i.e. stop the world).

[MikeHolman]

On Windows you can use ZeroMemory+VirtualUnlock, which will achieve the same effect and not require any synchronization.

[lukewagner]

Calling VirtualUnlock on a range of memory that is not locked releases the pages from the process's working set.

Whoa, never noticed that; thanks! Searching a bit more about this pattern turned up this post by Raymond Chen on the topic. So it sounds like the ZeroMemory + the zero optimization mentioned in that post ensure that an all-zero page isn't written to the pagefile.

The other possible cost of this approach is the extra work to (1) zero the pages, (2) detect all-zeroes but I was wondering if maybe ZeroMemory (in large-size cases) does a syscall to clear the dirty bit. This other post and this comment come tantalizingly close to answering the question but I couldn't find a follow-up post; do you know?

[MikeHolman]

I think the post you linked first is the follow-up. ZeroMemory just calls memset in all cases, so there is definitely some work involved. For non-shared memory VirtualFree(MEM_DECOMMIT);VirtualAlloc(MEM_COMMIT) might be best, but at least this gives a better/easier option for shared memory.

[lukewagner]

Well, I was hoping for a follow-up to the follow-up then :) But you're right, seems way easier to zero+unlick for shmem than pull out the signal hammer.

[binji]

This is a useful feature, but probably should be its own proposal at this point.