To follow up on my own message, adding:

#define LIST_FIRST(head)        (head)->lh_first
#define LIST_NEXT(elm,next)     (elm)->next.le_next

	to mmalloc.c will let it compile (and it appears to work), but
	its quite possible I've done something wrong :)

		David/absolute

                  -=-  "Why am I seething with this animosity"  -=-

On Wed, 6 May 1998, David Brownlee wrote:

> 	Does the machine need to be running a -current to work?
> 	compiling it on a 1.3.1 box gives:
> mmalloc.c: In function `mmalloc_find':
> mmalloc.c:33: warning: assignment makes pointer from integer without a cast
> mmalloc.c:35: `next' undeclared (first use this function)
> mmalloc.c:35: (Each undeclared identifier is reported only once
> mmalloc.c:35: for each function it appears in.)
> mmalloc.c:35: warning: assignment makes pointer from integer without a cast
> 
> 	Hmm.. I can't find the LIST_FIRST or LIST_NEXT macros on either
> 	a 1.3.1 or -current tree... What am I doing wrong!? :)
> 
> 		David/absolute
> 
>  -=-  "I know its not the right thing, and I know its not the good thing"  -=-
> 
> On Wed, 6 May 1998, Chuck Silvers wrote:
> 
> > my theory on this was that it was horrible memory fragmentation
> > caused by netscape displaying lots of images of widely varying size,
> > and the system malloc not dealing with this particularly well.
> > I hacked up a version of malloc() that uses mmap() to satisfy
> > requests of more than pagesize, which has the advantage that
> > freeing these blocks with munmap() will actually release the
> > memory back to the system.  this is at
> > 
> > 	http://www.chuq.com/netbsd/mmalloc.tar.gz
> > 
> > to build, copy netbsd's src/lib/libc/stdlib/malloc.c into the
> > mmalloc directory and "make".  to use, install the resulting
> > shared library somewhere and setenv LD_PRELOAD to point to it.
> > I only use it for my X server (via a .xserverrc), but it
> > should work for everything.
> > 
> > I haven't had my X server die from lack of memory since then,
> > but then I've added more RAM and swap to my machine also,
> > so I'm not sure which is responsible.  it was a fun hack
> > either way.  one funny side-effect of this is that memory
> > allocated with mmap() doesn't show up in ps, so it's hard
> > to tell how much memory the process is really using anymore.
> > I wrote another little program to dump a process's vm_map
> > via /dev/kmem, but the output isn't so useful since it's hard
> > to tell what's what.
> > 
> > -Chuck
> 
> 
>