www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/02/06/03:39:30

Subject: Re: malloc/free ends up fragmenting dynamic memory?
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Tue, 6 Feb 1996 09:36:55 +0100 (MET)
Cc: 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
'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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019