+By default, Linux follows an optimistic memory allocation strategy.
+This means that when
+.BR malloc ()
+returns non-NULL there is no guarantee that the memory really
+is available.
+In case it turns out that the system is out of memory,
+one or more processes will be killed by the OOM killer.
+For more information, see the description of
+.IR /proc/sys/vm/overcommit_memory
+and
+.IR /proc/sys/vm/oom_adj
+in
+.BR proc (5),
+and the Linux kernel source file
+.IR Documentation/vm/overcommit-accounting.rst .
+.PP
+Normally,
+.BR malloc ()
+allocates memory from the heap, and adjusts the size of the heap
+as required, using
+.BR sbrk (2).
+When allocating blocks of memory larger than
+.B MMAP_THRESHOLD
+bytes, the glibc
+.BR malloc ()
+implementation allocates the memory as a private anonymous mapping using
+.BR mmap (2).
+.B MMAP_THRESHOLD
+is 128\ kB by default, but is adjustable using
+.BR mallopt (3).
+Prior to Linux 4.7
+allocations performed using
+.BR mmap (2)
+were unaffected by the
+.B RLIMIT_DATA
+resource limit;
+since Linux 4.7, this limit is also enforced for allocations performed using
+.BR mmap (2).
+.PP
+To avoid corruption in multithreaded applications,
+mutexes are used internally to protect the memory-management
+data structures employed by these functions.
+In a multithreaded application in which threads simultaneously
+allocate and free memory,
+there could be contention for these mutexes.
+To scalably handle memory allocation in multithreaded applications,
+glibc creates additional
+.IR "memory allocation arenas"
+if mutex contention is detected.
+Each arena is a large region of memory that is internally allocated
+by the system
+(using
+.BR brk (2)
+or
+.BR mmap (2)),
+and managed with its own mutexes.
+.PP
+SUSv2 requires