Re: Proposed approach for malloc to deal with failing brk

[Szabolcs Nagy <nsz@port70.net>]

* Rich Felker <dalias@aerifal.cx> [2014-03-30 20:41:04 -0400]:
> We want brk. This is not because "brk is faster than mmap", but
> because it takes a lot of work to replicate what brk does using mmap,
> and there's no hope of making a complex dance of multiple syscalls
> equally efficient. My best idea for emulating brk was to mmap a huge

another reason to have brk: on some archs there is a TASK_UNMAPPED_BASE
limit in the kernel (1G normally) and mmap can only allocate above that

a large part of the first 1G is used for brk only (and top 1G is kernel)

so an mmap only allocator would limit the malloc space to 2G
(at least 32bit arm and mips i think)

> Once brk has failed, begin obtaining new blocks to add to the heap via
> mmap, with the size carefully chosen:
> 
>     MAX(requested_size, PAGE_SIZE<<(mmap_cnt/2))

yes this works, i added a regression test for brk failure