> Since malloc() in libc uses brk, no language with C bindings can use brk.
Afaik there is no such thing as "malloc in libc", each libc has its own allocator which does its own thing, OpenBSD's hasn't used (s)brk in 15 years and Dragonfly pulled that in way back[0]. And freebsd's system allocator is jemalloc which can use mmap or sbrk (if the latter is available and compiled in) but will prefer mmap (unless otherwise configured, though that knob may have been removed since I last checked):
> Traditionally, allocators have used sbrk(2) to obtain memory, which is suboptimal for several reasons, including race conditions, increased fragmentation, and artificial limitations on maximum usable memory. If sbrk(2) is supported by the operating system, this allocator uses both mmap(2) and sbrk(2), in that order of preference; otherwise only mmap(2) is used.
More broadly, (s)brk is considered deprecated in most if not all BSDs
* OpenBSD: The brk() and sbrk() functions are historical curiosities left over from earlier days before the advent of virtual memory management.
* FreeBSD: The brk() and sbrk() functions are legacy interfaces from before the advent of modern virtual memory management. They are deprecated and not present on the arm64 or riscv architectures. The mmap(2) interface should be used to allocate pages instead.
* macOS: The brk and sbrk functions are historical curiosities left over from earlier days before the advent of virtual memory management.
* NetBSD: The brk and sbrk functions are legacy interfaces from before the advent of modern virtual memory management.
And while glibc might use (s)brk, it hopefully doesn't bother releasing the (s)brk allocations as that would be a significant amount of work for usually no ability to release anything anyway (unless it's an arena-type use), meaning others can probably (s)brk as well, as long as they don't assume they're the only caller.
An other point of interest: on Solaris[1] and its descendants ([2], [3]) not only is mmap(2) recommended, the manpage plain tells you
> The behavior of brk() and sbrk() is unspecified if an application also uses any other memory functions (such as malloc(3C), mmap(2), free(3C)).
Afaik there is no such thing as "malloc in libc", each libc has its own allocator which does its own thing, OpenBSD's hasn't used (s)brk in 15 years and Dragonfly pulled that in way back[0]. And freebsd's system allocator is jemalloc which can use mmap or sbrk (if the latter is available and compiled in) but will prefer mmap (unless otherwise configured, though that knob may have been removed since I last checked):
> Traditionally, allocators have used sbrk(2) to obtain memory, which is suboptimal for several reasons, including race conditions, increased fragmentation, and artificial limitations on maximum usable memory. If sbrk(2) is supported by the operating system, this allocator uses both mmap(2) and sbrk(2), in that order of preference; otherwise only mmap(2) is used.
More broadly, (s)brk is considered deprecated in most if not all BSDs
* OpenBSD: The brk() and sbrk() functions are historical curiosities left over from earlier days before the advent of virtual memory management.
* FreeBSD: The brk() and sbrk() functions are legacy interfaces from before the advent of modern virtual memory management. They are deprecated and not present on the arm64 or riscv architectures. The mmap(2) interface should be used to allocate pages instead.
* macOS: The brk and sbrk functions are historical curiosities left over from earlier days before the advent of virtual memory management.
* NetBSD: The brk and sbrk functions are legacy interfaces from before the advent of modern virtual memory management.
And while glibc might use (s)brk, it hopefully doesn't bother releasing the (s)brk allocations as that would be a significant amount of work for usually no ability to release anything anyway (unless it's an arena-type use), meaning others can probably (s)brk as well, as long as they don't assume they're the only caller.
An other point of interest: on Solaris[1] and its descendants ([2], [3]) not only is mmap(2) recommended, the manpage plain tells you
> The behavior of brk() and sbrk() is unspecified if an application also uses any other memory functions (such as malloc(3C), mmap(2), free(3C)).
[0] https://bugs.dragonflybsd.org/issues/84
[1] https://docs.oracle.com/cd/E88353_01/html/E37841/sbrk-2.html
[2] https://illumos.org/man/2/sbrk
[3] https://smartos.org/man/2/sbrk