17 ms·

On Windows you can achieve something like manual overcommit by calling VirtualAlloc with just MEM_RESERVE. That gives you a continuous space in your process's v

On Windows you can achieve something like manual overcommit by calling VirtualAlloc with just MEM_RESERVE. That gives you a continuous space in your process's virtual address space, without actually backing it with any physical pages. Kind of like what a malloc does on linux But where linux would automagically back those pages once you use them, Windows requires you to actually ask for those pages to be backed by something (physical memory or page file) by calling VirtualAlloc with MEM_COMMIT on the range you actually want to use

fc417fc802 5d ago
At a glance that seems like a much more sensible design. I guess it's dead in the water for posix on account of fork being CoW? This is quite the rabbit hole. I wonder if programming languages ought to be designed in such a way to accommodate a preemptive signal indicating allocation failure in place of a page fault? Rather than malloc returning null or etc.
- toast0 5d ago
  > I guess it's dead in the water for posix on account of fork being CoW? If that's the only issue, it's avoidable for most use cases. Lots of processes that fork are doing fork/exec to run a helper program. If they know they will do that and that they will be a large process, it's often useful to setup a fork/exec helper in early application startup. However, there are some applications that use CoW more intentionally. Lock -> fork -> (unlock in parent / persist coherent snapshot in child) is a common pattern; I believe redis uses thst pattern and I've seen it mentioned in discussions about MMO servers. I believe postgres uses fork and CoW for transaction isolation ... but postgres also runs on Windows so there must be another way or I don't understand. For the persist case, you could imagine some sort of flag to fork to allow overcommit and maybe even to let CoW requests stall in the parent rather than fail... the child is expected to do its work and exit in a limited time.

fc417fc802 5d ago

At a glance that seems like a much more sensible design. I guess it's dead in the water for posix on account of fork being CoW? This is quite the rabbit hole. I wonder if programming languages ought to be designed in such a way to accommodate a preemptive signal indicating allocation failure in place of a page fault? Rather than malloc returning null or etc.

toast0 5d ago
> I guess it's dead in the water for posix on account of fork being CoW? If that's the only issue, it's avoidable for most use cases. Lots of processes that fork are doing fork/exec to run a helper program. If they know they will do that and that they will be a large process, it's often useful to setup a fork/exec helper in early application startup. However, there are some applications that use CoW more intentionally. Lock -> fork -> (unlock in parent / persist coherent snapshot in child) is a common pattern; I believe redis uses thst pattern and I've seen it mentioned in discussions about MMO servers. I believe postgres uses fork and CoW for transaction isolation ... but postgres also runs on Windows so there must be another way or I don't understand. For the persist case, you could imagine some sort of flag to fork to allow overcommit and maybe even to let CoW requests stall in the parent rather than fail... the child is expected to do its work and exit in a limited time.