It turns out #21582 causes big problems for fork on Cygwin. This is due to an implementation detail of how Cygwin handles copy-on-write private mappings when forking. A fact that might, unfortunately, be difficult to avoid. The problem with this on Cygwin is that, while Windows does not commit pages to physical memory until they are accessed, they do become committed upon any access (even reads, when they haven't already been written to).

So when a process with a private mmap is forked, it loops over all pages in the mmap'd region and copies them into the child's copy of the mmap'd region. This results in committing physical memory on both the parent and the child, even for pages that haven't been written to yet.

TL;DR, if there's a huge private|anonymous mmap in a process, and that process is forked, it will commit the full size of the mmap to memory in both the parent and child processes.

This is a big problem in Sage since we set a very large default stack size for Pari. This was not a problem prior to #21582, since Pari used the MAP_NORESERVE flag which circumvents this issue (only dirty pages need to be copied). The changes in #21582 make sense for Linux, but for Cygwin the opposite is true. Different but unfortunate implementation details on both platforms.

The best way forward is to use MAP_NORESERVE anyway, which helps Cygwin and won't hurt other platforms.

Upstream bug: https://pari.math.u-bordeaux.fr/cgi-bin/bugreport.cgi?bug=1912

Upstream: Fixed upstream, but not in a stable release.

CC: @jdemeyer

Component: porting: Cygwin

Keywords: days85 windows cygwin pari mmap

Author: Erik Bray, Jeroen Demeyer

Branch/Commit: 343f241

Reviewer: Erik Bray, Jeroen Demeyer

Issue created by migration from https://trac.sagemath.org/ticket/22633