Comment #0 by dlang-bugzilla — 2024-01-11T10:58:04Z
When the GC tries to allocate some memory and has none available in the pools it already acquired from the OS, it uses a heuristic to decide whether to trigger a collection cycle or to just request more memory from the OS.
There are some allocation patterns that may cause it to request the last bit of memory from the OS, even though a collection could otherwise satisfy that demand for memory. When this happens, no more memory can be allocated from anywhere in the program, including from C code using malloc.
Though programs generally do not "run out of memory" on modern systems, due to the prevalence of virtual memory, it can still happen if the virtual memory size is limited by `ulimit -v`, or the program runs in a container/cgroup which imposes a memory limit.
This becomes a problem when trying to interoperate with C libraries (as most D programs ultimately do). For example, one symptom of this is std.net.curl requests failing with "Out of memory on handle XXXXXXXXX".
Ideally, the GC should stop allocating (if it can avoid doing so) when the total program memory usage approaches the total program memory limit, though querying these two figures may not be straight-forward on all platforms.
https://github.com/dlang/dmd/blob/4fc086b0c9d08a5bcdabecdec441ec779462181e/druntime/src/core/internal/gc/os.d#L213-L215
Comment #1 by robert.schadek — 2024-12-07T13:43:11Z