Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!CS.TORONTO.EDU!moraes
From: moraes@CS.TORONTO.EDU (Mark Moraes)
Newsgroups: comp.sys.sgi
Subject: Re: The memory eater strikes back (2nd attempt to get attention)
Message-ID: <89Oct21.211825edt.3287@neat.cs.toronto.edu>
Date: 22 Oct 89 01:18:19 GMT
References: <8910210901.aa24434@SMOKE.BRL.MIL>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 39

In comp.sys.sgi you write:

>a) Is it my fault (using wrong library order?)?

Nope. Even if you remove all libraries except for -lmalloc, it still
grows. You can see the problem over only a couple of iterations by
printing the value of sbrk(0) after every loop. The break will grow
steadily when using -lmalloc or amalloc/afree from -lmpc. With libc
malloc, the BSD4.3 malloc or any other working malloc, the value stays
constant after the first iteration.

>b) Is it a bug?
>   - known?
>   - fixed when?

Looks like a bug. Not fixed in Irix 3.2, it seems.

>c) Is there really a performance gain when using -lmalloc (supposed it
>   works properly)?

Not likely if it doesn't free...

The standard libc malloc is about the speed of the "fast" BSD4.3
(Caltech) malloc for your example code (which is straight allocation
followed by free -- not very demanding on most mallocs).  But the
Caltech malloc typically wastes twice as much memory, which can cause
more paging if you use a lot of memory.  (If free() doesn't work in
-lmalloc, it isn't very useful, no matter how fast it is -- on our
Power Iris, it takes about twice as long as the libc malloc...)

The libmpc amalloc and afree show the same behaviour as -lmalloc if you
modify your code to acreate an arena first, and add a grow function.

Stay with the libc malloc unless profiling your application indicates
that malloc is a bottleneck. At that point, consider custom allocation
strategies for the most frequent uses of malloc. (like preallocating
and managing memory pools of frequently used objects, using pages of
memory where only the page is freed, using stack allocators with
mark/release etc)