Subject:	Re: malloc/free ends up fragmenting dynamic memory?
To:	kuku AT gilberto DOT physik DOT RWTH-Aachen DOT DE
Date:	Tue, 6 Feb 1996 10:35:10 +0100 (MET)
Cc:	eliz AT is DOT elta DOT co DOT il, beale AT leland DOT Stanford DOT EDU, djgpp AT delorie DOT com
From:	Christoph Kukulies <kuku AT gilberto DOT physik DOT rwth-aachen DOT de>
Reply-To:	Christoph Kukulies <kuku AT gilberto DOT physik DOT rwth-aachen DOT de>

> 
> > 
> > 
> > On 5 Feb 1996, John Beale wrote:
> > 
> > > I am guessing that the many malloc/free operations fragments the memory
> > > store analgous to hard disk filesystem fragmentation with many saves and
> > > deletes, such that a contiguous memory segment for a large malloc() can no
> > > longer be found. Is there a malloc_unfragment() command or equivalent?  How
> > > do other people handle this problem?
> 
> I had to fight a similar problem these days and have been pointed to 
> PD (though uniox based but maybe easily portable) diagnose tool, called
                x

Following my own message I must correct myself WRT 'leak'.
I tested it and it does by far not what I expected. It also isn't
portable (uses unix dbm routines - which don't exist under DOS/djgpp afaik)

It does no boundary checking. It just gives you statistics where
allocs, reallocs and frees happened in your program by including the
following leak.h into your sources:

#define malloc(s) \
  (_ptr = malloc(s), _dbinsert(_ptr, s, __FILE__, __LINE__, DBM_INSERT), _ptr)
 

> 'leak' (comp.os.unix.sources/volume00/leak - try archie leak).
> 
> I have not tested it yet but it may do what I want - diagnosing
> my code or others code for memory leaks, too short allocates etc.
> 
> 
> There are also various alternative allocators. BTW, FreeBSD has now
> a nice diagnosing allocator which can be activated/strength increasable
> by an environment variable. You may obtain FreeBSD from somewhere
> and test your code there.
> 
> 
> > 
> > This is a problem with many implementations of `malloc', the one from 
> > DJGPP library included.  The usual method of solving such problems in 
> > programs that allocate and free many small arrays, is to allocate a large 
> > buffer of memory and use parts of it as needed instead of calling 
> > `malloc' and `free'.
> > 
> > One piece of knowledge that might help you: the DJGPP `malloc' always
> > allocates blocks whose sizes are an integer power of 2; if you ask for
> > 32KB, you get 64KB (because of the 4-byte overhead of `malloc' itself). 
> > So you might make your problems easier if you never get too close to sizes
> > of the form 2^n for any integer n.
> > 
> > Another possibility, in the case that your allocations only last as long 
> > as the function which allocated them, is to use `alloca' instead (which 
> > allocates the memory from the stack).  This way, you don't have the 
> > fragmentation problem, and also are spared the need to call `free'.
> > 
> 
> --Chris Christoph P. U. Kukulies kuku AT gil DOT physik DOT rwth-aachen DOT de
> 

--Chris Christoph P. U. Kukulies kuku AT gil DOT physik DOT rwth-aachen DOT de

- Raw text -