Reduce memory usage on windows when running external programs

[embray]

This is a version of the patch from https://trac.sagemath.org/ticket/27214

TL;DR This is an issue that has come up in the past with Pari as well. When you mmap a large region of memory in Cygwin, and then fork() the process, the entirety of that region has to have physical memory committed to it.

This is a known issue on Cygwin and is sort-of by design (or rather a known limitation due to the underlying OS). The workaround, generally, is to use the non-POSIX MAP_NORESERVE flag which comes from Linux, but has slightly different, albeit similar implications.

For now we just use the MAP_NORESERVE flag on Cygwin, though it could be used on Linux as well. The implication is that it is possible to reserve a larger region of memory even if there are not enough physical pages at the time of the mmap() call to fill the entire region (though if there is enough physical memory later then it's no problem). The main downside to this is that if you reach a point where you do run out of physical memory to handle writes to the mmap'd region, then the application will crash (segfault most likely). Though I haven't tried to reproduce such a situation in GAP.

[ChrisJefferson]

Interesting. On Linux we assume people haven't disabled over-commit, as the 64-bit GAP can reserve very large chunks of memory space upfront, which we assume will be allocated lazily when we use it.

Therefore I don't think this will make anything worse, and might well make cygwin better (particularly as we move to larger 64-bit memory spaces)

[coveralls]

Coverage remained the same at 85.075% when pulling d0f592a on embray:kernel/cygwin-alloc-pool into 1213dab on gap-system:master.

[embray]

On Cygwin you're ultimately dealing with the Windows memory manager, so some things are different, and what MAP_NORESERVE does has much stronger implications there. Without it, it's like Linux with overcommit turned off: You can't return an mmap larger than the system's combined RAM and swap space. Memory isn't used immediately but it's essentially "reserved" for that process.

[embray]

One could also argue that it would be better, rather than making this fix Cygwin-specific, there should be no harm in passing MAP_NORESERVE on Linux or in principle other platforms where it's defined. I think it is ignored if overcommit is disabled anyways.

For starters I kept it Cygwin-specific, but if you agree I could change that.

[embray]

Any thoughts on the question of not making this cygwin-specific?

[ChrisJefferson]

If we don't need it on Linux, I'd probably leave it, just because this code has in the past proved to be sensitive to changes causing problems on weird BSDs like DragonFly and the like, so (personally) I try not to change the memory allocation unless we are fixing a specific issue (like this one).