Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!CSRI.TORONTO.EDU!moraes
From: moraes@CSRI.TORONTO.EDU (Mark Moraes)
Newsgroups: comp.sys.sgi
Subject: Re: The memory eater strikes back (2nd attempt to get attention)
Message-ID: <8910240037.AA14873@steeles.csri.toronto.edu>
Date: 24 Oct 89 00:37:28 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 54


 | The libc malloc slows considerably when dealing with many small object
 | allocations and deallocations (typically a few hundred thousand if I
 | remember right) where the BSD malloc degrades "reasonably"; pooled
 | allocations will improve performance dramatically if you are doing
 | this type of allocation on the SGI.

True. I should also amend my earlier comment: For large numbers of
small allocations, -lmalloc does indeed perform much faster than even
the BSD4.3 malloc (and appears to free stuff correctly) For the
specific case posted, it does not free correctly, and runs much
slower.  There are similar cases where the BSD malloc, while not
losing performance in terms of CPU, will gobble up memory and causes
paging activity.  (eg. allocate a 1000 elements of 50 bytes each, free
them all, then allocate a single element of 2000 bytes and watch it
sbrk again, unnecessarily)

 | The libmalloc malloc, even if broken, is good to run some tests with
 | because it smashes the malloc'ed area; we found many bugs beca | use of
 | this behavior (and even more when running on a machine which
 | disallowed null pointer dereferencing :-).

Huh? In Irix3.2, it doesn't necessarily smash the contents of freed
blocks (I assume you mean smash the malloc'ed area on free -- I'd be
rather displeased with a malloc that trashed the contents of the
malloc'ed blocks:-) The following program prints hello world twice
even when compiled with -lmalloc. Change that to "hello
xxxxxxxxxxxxxxxxxxxxxxxxxxxx world" and it will then smash the freed
block.

Smashing the contents of a freed block (among other things) is
desirable behaviour in a debugging malloc -- it degrades performance
enough that you probably don't want it in your final code.

-lmalloc won't work with the old kludge where you were allowed to rely
on a freed block being undamaged till the next malloc. -lmalloc also
returns NULL on malloc(0), following the SVID. Both are good for
people who care about portability.

#include <stdio.h>

#define HELLO "hello world\n"

main()
{
    extern char *malloc();
    char *cp = malloc(sizeof(HELLO));

    strcpy(cp, HELLO);
    fputs(cp, stdout);
    free(cp);
    fputs(cp, stdout);
    exit(0);
}