Path: utzoo!attcan!uunet!lll-winken!ames!pasteur!ucbvax!adt.UUCP!madd
From: madd@adt.UUCP (jim frost)
Newsgroups: comp.sys.sgi
Subject: Re: -lmalloc
Message-ID: <8901301441.AA06632@adt.uucp>
Date: 30 Jan 89 14:41:21 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 46

>We have several personal Iris's running IRIX 3.1.  We have ported some
>software from BSD systems, and found that there is a difference
>between the C function malloc in /usr/lib/libbsd.a and
>/usr/lib/libmalloc.a.  In particular the malloc in the latter library
>is 8 times faster (by our estimates) than the malloc in the bsd
>library (or the malloc provided with gnu emacs).
>
>But there is also something strange with -lmalloc.  Sometimes,
>programs which execute perfectly with the bsd malloc, core dump when
>the other malloc is invoked.  For example, using X lib with bsd malloc
>is ok, but with lmalloc core dumps occur.
>
>Can somebody explain what the exact difference between these two
>functions are?

I can't give you the exact difference but I can tell you a little
about it.

The libmalloc.a malloc() call uses a different internal format than
the default malloc(), and has much greater speed -- particularly with
lots of small allocations.  One of the changes between the two
malloc()'s is that the libmalloc.a version trashes the malloc()'ed
area after it was free()'ed.  My guess is it slams a pointer into the
area, which would be consistent with the man page.  If a program uses
the area after it's been free()'ed, it's likely to break.  This was
the case for our application, and it's probably the case with X.  If
you haven't noticed, much of X seems to be a hack.

Another difference between the libmalloc.a malloc() and the normal one
is the ability to adjust the tuning of its malloc (through mallopt())
and to turn on debugging.  This debugging feature is very useful in
finding which routine overran the bounds of a malloc()'ed region,
which is why we were using it.

At first I wondered "why don't they just make it the standard malloc
if it's so fast", but since so many programs incorrectly use space
which has been free()'ed (smashing both the program and malloc()'s
lists), it would be counterproductive -- especially considering the
number of annoyances which programmers have to put up with already on
the SGI.

Happy hacking,

jim frost
associative design technology
madd@bu-it.bu.edu