4 ms·
This sounds so ancient, but I clearly remember seeing the sbrk() system call happening a lot when strace'ing processes on Linux, so it can't be much more than 2
by anyfoo 5y ago
This sounds so ancient, but I clearly remember seeing the sbrk() system call happening a lot when strace'ing processes on Linux, so it can't be much more than 20 years ago, or maybe much less even. When did allocators on Linux stop doing that? glibc?
EDIT: Never mind, the article answers that eventually, it's still used apparently: "I know that GNU libc does use brk() based allocation for programs that only make small allocations, for example /usr/bin/echo."
- jeffbee 5y agoThe old, original tcmalloc that is still widely used starts out using sbrk and only switches to mmap if it exhausts the heap. So if you trace a program using gperftools/tcmalloc you could expect to see plenty of sbrk. (The newer hugepage-aware tcmalloc never uses sbrk.)
- pchanda 5y agoWhat do you mean when you say it exhausts the heap? I understand that the stack size is fixed but can't the heap grow unbounded using sbrk till it exhausts the address space?
- guerrilla 5y agoI don't know anything aboug tcmalloc specifically but if the program is not mapped at 0, then there's space below it as well. The heap can meet the stack using sbrk while memory below where the program is could still be mmapped. This was the case on x86-32 anyway. On x86-64 programs are mapped much lower (on my system anyway.)
- Taniwha 5y agoI think they mean that it grows to the point where it collides with the virtual address space allocated to another block (the stack, a shared library, a mmap'd area etc)