[re sbrk/brk going away]

>> At least not until someone has reimplemented malloc in terms of some
>> other system call, e.g. mmap.
> right.  but i can think of very few reasons why "application
> software" (i.e. anything that's not a system library or the kernel)
> would need to know about them...

Speaking as someone who's written software that uses sbrk(), the first
two reasons that come to mind are (a) to allocate large chunks of
memory that will never be freed, without the space wastage malloc()
often produces, and (b) for anything that needs a memory allocator more
sophisticated than malloc().

The first item is important if you're allocating multiple megabytes,
because malloc() typically wastes a lot of space - it adds a small
constant and then rounds up to a power of two; if you're allocating a
power-of-two amount, this wates approximately as much space as you
allocate.  I don't know offhand whether NetBSD malloc is this stupid,
but my code certainly cannot count on anything brighter, which is why I
use sbrk().

The second item seems obvious, but nobody's mentioned it yet that I've
seen.  I have at least two programs that do their own memory management
(they are implementations of garbage-collected languages), and don't
need the extra services malloc() provides over sbrk(), and don't want
the memory overhead either.  So I use sbrk().

Actually, on the NeXT I use vm_allocate(), because for all their
vaunted UNIX compatability, they couldn't be bothered to implement
sbrk(), at least not at the release I'm stuck at.  So it would be
relatively easy to switch them around to mmap()ping anonymous memory,
or some other such scheme.  But IMO _some_ mechanism should be exported
for user-land to get memory without the time and space overheads
imposed by malloc().  And indeed, on any system where malloc() is
itself user-land code, there must be such a mechanism...but it would be
nice if people could settle on it, document it, and then let programs
use it.  I used to think sbrk() was that mechanism, but NeXT burst that
bubble, and now it sounds as though there's reason to think it might
vanish from BSD as well.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu