Front page | perl.perl5.porters |
Postings from September 2014
Dave Mitchell <davem@iabyn.com> wrote: > I haven't researched this properly yet (I'm secretly hoping I wont have to > and someone already knows the answers). I don't claim a great deal of expertise here, but as I understand it, the glibc malloc switches to a different strategy for allocations in excess of 128 KiB (tunable; see mallopt(3)). For small allocations, it allocates an arena using sbrk(2), and manages it in the obvious sort of way. For large allocations, it uses mmap(2) to create a private mapping (which therefore has to be a multiple of the MMU page size, typically 4096 bytes). Further, strace(1) tells me that when glibc is asked to realloc a large allocation, it uses mremap(2) to do so. This means that extending large allocations can be done without actually copying the data: the kernel merely rejigs the virtual memory mapping so that all the pages (whether previously or newly allocated) form a contiguous part of the process's virtual address space. -- Aaron Crane ** http://aaroncrane.co.uk/Thread Previous | Thread Next