3 ms·

I thought modern systems allocated heap memory using mmap - I didn't realise the heap start and the heap break were still a done thing?

• cperciva 4y ago
  You're right -- about modern systems. The article is aimed at embedded systems, which are generally less than modern.
  • comex 4y ago
    Any software written for microcontrollers or other low-memory environments is probably not going to use mmap or, more generally, anything that dynamically manipulates memory mappings (if there even is an MMU in the first place). That said, the specific use of a function called sbrk seems odd and maybe archaic, since it has no useful role if the heap is fixed-sized anyway. But it looks like newlib (the libc being used here) uses _sbrk as part of an abstraction that supports many different environments [1], including not just bare metal but also running as a userland program under Linux and other kernels. So maybe it makes sense. [1] https://github.com/eblot/newlib/search?q=_sbrk&type=code https://github.com/eblot/newlib/search?q=_sbrk&type=code
• saagarjha 4y ago
  I believe the glibc allocator uses sbrk on the main thread or something like that.
• stefan_ 4y ago
  On a bare metal system, the heap is just a bunch of values in a linker script.
• 8jy89hui 4y ago
  The kernel is forced to zero memory that is allocated with mmap. This is very expensive and it is better to use sbrk and re-use allocated memory when possible. As such, the glibc malloc uses a sliding threshold to ensure that large long-lived allocations are mmaped whereas short allocations live inside "arenas" which are basically giant doubly linked lists that can expand with sbrk.