3 ms·
Yeah malloc is user space code, but it will do a syscall like sbrk to actually get memory from the kernel. The default malloc in glibc does not pad the values
by dahfizz 4y ago
Yeah malloc is user space code, but it will do a syscall like sbrk to actually get memory from the kernel.
The default malloc in glibc does not pad the values given to sbrk, so you have to do a syscall for every 4k chunk of memory (the pagesize). So unless you do lots of very small (<<4k) allocations, you call sbrk pretty often.
You will also page fault when you access the new pages, and this traps into kernel code again.
So yeah, you are technically correct that some allocations may be fast because the memory is already available and mapped. Allocations, on average, are still slow because it involves context switches to the kernel (potentially multiple).
TLDR: you make it sound like a syscall within malloc is rare, but many/most allocations will trigger a syscall.
- morelisp 4y agoIt is rare because one of the very first things anyone does if they're concerned about allocations is replace glibc malloc.
- Agingcoder 4y agoNo, for a start some allocators don't even use sbrk (all mmap), and glibc's ptmalloc will use mmap for large allocations, ie you can allocate multiple megabytes with a single syscall with ptmalloc. Granted, if memory has been mmaped, you will pay a page fault because of the zero page optimization when you first write to it. Furthermore, memory which is freed is often not returned to the os, either for fragmentation (you've used sbrk..) , or performance reasons (minimize syscalls), and put in a free list instead. The next call to malloc then will not require a syscall, if it can be satisfied with existing freed blocks.