Re: alloc.c

>     I noticed that fefe's latest ucspi-tcp patch ditches
> alloc/alloc_free and invokes malloc/free directly.  I wonder if that's
> because he decided the BSS array optimization was no longer a benefit

 Have a look at the following thread, in which Nikola suggests adding
the alloc() optimization to the dietlibc and I convince him it's a
bad idea:

http://thread.gmane.org/gmane.linux.lib.dietlibc/1374

 I think Felix did the same reasoning as me (let him say otherwise
if he disagrees, he's reading this list): unless you want to give
the guarantee that your program does not use malloc() at all, the
alloc() optimization is useless.
 Also, Felix dislikes wrappers.
(see http://www.fefe.de/dietlibc/diet.pdf )


> or if it's just that he's linking against dietlibc, which presumably
> has a decent malloc() implementation?

 I don't think the decision is dietlibc-related. I'm not aware of
any Unix kernel+libc combination with a notoriously slow malloc().
malloc() is so essential that Unix developers try to at least do
that part right, I guess.
 GNU overdoes it (like most of the things they do :)), so the glibc
malloc() is incredibly bloated, but it's still fast.
The dietlibc malloc() gains in simplicity, and code size, but I
wouldn't bet on it about speed (have any benchmarks be made ?)
 And there's no reason a BSS array would be useful in one case and
not in the other.

( Technically, the first malloc() you do causes *two* system calls
with the glibc (brk(0) to know where the data segment ends, then
a second brk() call to increase its size; whereas it causes only
*one* system call, mmap(), with the dietlibc. So if you never need
to extend the data segment anymore / get another page from the kernel,
the dietlibc implementation saves one system call. I honestly believe
it's thoroughly and utterly negligible - especially considering that
your glibc-using program will probably be dynamically linked and your
dietlibc-using program will probably be statically-linked, so the glibc
version is going to perform at least a dozen more system calls when
resolving dynamic symbols anyway.
 My point is, the ONLY reason to use DJB's alloc() is if you want to
be able to say "this program never calls malloc()". Any performance
consideration is such a drop in the water that it's totally ridiculous. )

-- 
 Laurent