As discussed in #27213, when we initialize libgap, we pass it the -s flag which according to the docs is 'set the initially mapped virtual memory', to a size determined by sage.interfaces.gap.get_gap_memory_pool_size(), which on my system happens to be ~3GB.

This is fine, in general, as it's an amount that's available to my system. Nonetheless, in most usage (especially e.g. in the test suite) most of this will not be used.

I have to look into exactly how this memory gets allocated, but however it's being allocated it is unfortunately "committed" memory, meaning that although those pages are allocated lazily, they are guaranteed by the system to be made available for that process, so regardless whether those pages are actually in RAM, space is still reserved for them. So perhaps it uses sbrk to expand the process's heap. When the process is forked, Cygwin's fork() has to copy the parent process's heap into the child. This has the unfortunate effect of accessing those pages, causing them to become allocated in physical memory (even, apparently, if they're clean / unused).

This is essentially the same issue we faced with PARI in #22633, but applied to GAP. In fact, GAP's code sets the default value of the -s flag to 0 on Cygwin, presumably for reasons related to this. This might be possible to avoid, as was done in PARI, by instead allocating this memory with mmap and MAP_NORESERVE.

Upstream PR: gap-system/gap#3335

Depends on #27070
Depends on #27490

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

Component: porting: Cygwin

Author: Erik Bray

Branch/Commit: 4b359de

Reviewer: Jeroen Demeyer

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