I don't understand the difference between MEM_RELEASE and MEM_DECOMMIT in the Windows VirtualFree function.
Conversation
Replying to
MEM_RELEASE will free the mapping completely like munmap on Linux, making the address space usable for other things.
MEM_DECOMMIT will release the memory but hold onto the reserve address space like clobbering a mapping with mmap + MAP_FIXED + PROT_NONE on Linux.
2
2
Replying to
What does "hold onto" mean in this context? Does it mean the process continues to reserve the memory but the content pages are discarded?
1
1
Or does it mean the process continues to reserve the memory AND the pointer but the content is invalidated?
1
1
Replying to
It has the memory mapping but you can't use the memory because it's not committed, i.e. it can't assign pages to it if you touch it. It's just like having PROT_NONE mappings on Linux. The reason this exists is because Windows is designed around memory accounting, not overcommit.
1
1
Linux has a memory accounting mode via /proc/sys/vm/overcommit_memory and it just treats fresh PROT_NONE mappings the way Windows does MEM_RESERVE mappings.
Not really a way to do MEM_DECOMMIT on Linux other than clobbering with a new PROT_NONE mapping via mmap with MAP_FIXED.
If you purge all the pages from it on Linux with madvise + MADV_DONTNEED and then mprotect it back to PROT_NONE, the kernel still counts it against you for memory accounting. Have to clobber it with a fresh mapping to get a MEM_DECOMMIT equivalent which works fine but is odd.
Replying to
The codebase I'm editing has a linux implementation but not a windows implementation... the linux implementation is madvise(p, size, MADV_DONTNEED)
I'm replacing it with MEM_DECOMMIT
1
1
Replying to
The advantage of MEM_DECOMMIT and MEM_COMMIT is that the OS knows you don't need it during that time.
MADV_DONTNEED still keeps it as memory you can start using it at any point, and in memory accounting mode it gets counted against you.
1
3
Show replies