If malloc/free is implemented as a library routine in libc, then is it implemented on top of the sbrk syscall or the mmap syscall, or something else?
And to be general, does the function declared in sys/syscall.h contains ALL the system calls in the target machine?
Very often, malloc
and free
are using lower-level virtual memory allocation services and allocating several pages (or even megabytes) at once, using system calls like mmap and munmap (and perhaps sbrk). Often malloc
prefers to reuse previously free
d memory space when relevant. Most malloc
implementations use various and different strategies for "large" and "small" allocations, etc...
Notice that virtual address space can be limited, e.g. with setrlimit(2). Use on Linux pmap(1) and proc(5) to learn more about the virtual address space of some process (e.g. /proc/self/maps
for your own one or /proc/1234/maps
- also the pmap 1234
command - for process of pid 1234).
You could look at your GNU libc source code, look into the source code of other C standard libraries (such as musl-libc), read about malloc
implementations, choose some other ones or implement your own, or use strace to find out experimentally.
Read the syscalls man page (i.e. syscalls(2)) and the file <asm/unistd.h>
for a list of system calls.
malloc
(I believe that this could be the fastest implementation of malloc
; however it is not very useful; it is conforming to the standards)
I strongly believe that the C standard is very vague about malloc
and free
. I'm pretty sure that the following functions are respecting the letter (but not the spirit) of the standard:
/* politically incorrect, but very probably standard conforming */
void *malloc (size_t sz) { if (sz>0) errno = ENOMEM; return NULL; }
void free(void*ptr) { }
Of course you'll code calloc
and realloc
accordingly.
(BTW every code using malloc
should test against its failure, but some -incorrectly- don't; malloc
can return NULL
on failure and people should test against that case)
The GNU libc gives you hooks for your own malloc
functions (and you could even probably use Boehm's Garbage Collector transparently thru them). These hooks could become deprecated and are non-standard.
If using GNU libc, look also into mallinfo(3) and malloc_stat(3) and related functions.