sbrk(2) broken

[Peter Schuller]

> The real question is why we would revert perfectly good code (jemalloc)
> from using a modern interface to using one that has been obsolete for
> twenty years, and marked as such in the man page for seven years.

Also, may I humbly inject a user centric view here - it is pretty annoying to 
be limited to 500 MB of mallocable memory on 32 bit machines when you expect 
3 GB to be usable (with 1 GB mapped to the kernel).

I scratched my head for a long time as to why I was getting out of memory 
errors in spite of carefully setting resource limits and ensuring virtual 
memory was available; at some later point in time I discovered the hard-coded 
distinction between sbrk():able and mmap():able memory. I am not sure what I 
was supposed to find this in the documentation (I found it by chance 
Googling).

If sbrk() is indeed to be used by the default malloc, one definitely user 
visible annoyance will be the 500 MB limit. At least with mmap() that will be 
2.5 GB, unless I am misstaken, which is much closer to what one might expect 
and thus less likely to cause problems in the common case.

Changing maxdsize to be > 500 MB is probably bad too, from a user centric 
view, since you don't want to cause the equivalent problems for programs that 
do not use malloc(), but are indeed coded with "modern virtual memory" (as 
the man page calls it) in mind. Better to leave this problem to those 
programs that use sbrk() directly.

Another consequence is that if the sysadmin really wants a maximum amount of 
mmap():able memory, the maxdsize can presumably be lowered quite heftily 
without affecting the vast majority of applications. With malloc() use of 
sbrk() however, you will have mutual exclusivity between the common case 
(malloc() users), and special purpose applications that *do* try to be nice, 
modern and use mmap() instead of sbrk(). With mutual exclusivity between 
malloc() users and sbrk() users, at least you can kinda blame the sbrk() user 
for using an obsolete interface.

-- 
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller at infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey at scode.org
E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20080103/1864c08d/attachment.pgp