According to the Windows VirtualAlloc documentation, recent versions of Windows support "resetting" - calling VirtualAlloc with the MEM_RESET flag - which behaves essentially identically to madvise with MADV_DONTNEED on Linux and Mac:
Indicates that data in the memory range specified by lpAddress and dwSize is no longer of interest. The pages should not be read from or written to the paging file. However, the memory block will be used again later, so it should not be decommitted.
Similarly to madvise with MADV_WILLNEED, the MEM_RESET_UNDO flag is provided:
MEM_RESET_UNDO should only be called on an address range to which MEM_RESET was successfully applied earlier. It indicates that the data in the specified memory range specified by lpAddress and dwSize is of interest to the caller and attempts to reverse the effects of MEM_RESET. If the function succeeds, that means all data in the specified address range is intact. If the function fails, at least some of the data in the address range has been replaced with zeroes.
Questions:
How would we expose this? Right now, we use the commit/uncommit terminology and functions across all platforms, and simply document that they behave differently on Windows than on Linux/Mac. However, the behavior of resetting on Windows is essentially identical to what we currently call uncommitting on Linux/Mac. Thus, perhaps it'd be best to use commit/uncommit for Windows only, and come up with some other terminology to refer to MADV_DONTNEED/MEM_RESET and MADV_WILLNEED/MEM_RESET_UNDO.
These flags are only supported on recent versions of Windows (e.g., not even on Windows 7 desktop), so this feature couldn't be used universally. It would have to be used under conditional compilation flags.
Given a) the fact that adding this might require re-tooling the API and, b) the limited support, I'm inclined to leave this for now, but it may be worth coming back to in the future.
According to the Windows VirtualAlloc documentation, recent versions of Windows support "resetting" - calling
VirtualAllocwith theMEM_RESETflag - which behaves essentially identically tomadvisewithMADV_DONTNEEDon Linux and Mac:Similarly to
madvisewithMADV_WILLNEED, theMEM_RESET_UNDOflag is provided:Questions:
MADV_DONTNEED/MEM_RESETandMADV_WILLNEED/MEM_RESET_UNDO.Given a) the fact that adding this might require re-tooling the API and, b) the limited support, I'm inclined to leave this for now, but it may be worth coming back to in the future.