I believe that the malloc statements in my original post in this thread are 100% correct. At the risk of appearing to be trying to win an internet argument, I am dissecting your responses only in the hope that the thread contains useful and accurate information for those who may read it in the future.

Well, for the purposes of this discussion, physical memory is irrelevant; it's all about process virtual memory maps. Still, the statement isn't quite accurate. It implies that each segment is guaranteed to be fragmented in physical memory. It very well could be, but it's not a certainty.

OpenBSD uses malloc(), as do all UNIX/POSIX systems (to my knowledge).

You seem to be confusing interfaces that operate at different levels. mmap() is a lower level system call whose implementation is part of the kernel. malloc() is a higher level function whose implementation is part of the userland standard C library. malloc() does not directly allocate any memory; it must invoke a system call to do the job. The question is, which system call is used. Some malloc() implementations use brk()/sbrk(), some use mmap(), some use both.

If you're using Linux, you're almost certainly using glibc, and glibc's malloc implementation uses sbrk() for small allocations and mmap() for large ones.

FreeBSD tries to use mmap() for all allocations but if mmap() fails it will retry with sbrk().

OpenBSD's malloc() uses mmap() exclusively.

I believe OSX's malloc() uses mmap(), but I am not sure.

I could be mistaken, but I suspect that if there are any malloc() implementations still in widespread use which depend exclusively on brk()/sbrk(), they belong to the more conservative, proprietary Unices out there.

You are of course free to choose your nomenclature as you wish, but in this instance your usage is not in agreement with standard practice.

Being a rebel only makes life harder. Submit. Be one with the collective. Resistance is futile.

Regards,
Alister