Mail Archives: djgpp-workers/2002/05/16/16:47:00
Eli Zaretskii wrote:
>
> > Date: Thu, 16 May 2002 07:33:32 -0400
> > From: CBFalconer <cbfalconer AT yahoo DOT com>
> > >
> > > Actually, the main problem is to be able to join many small free'd chunks
> > > into larger chunks. If you fail to do that, you'll hit the problem of
> > > being unable to allocate memory for reading a file because the free pool
> > > is fragmented. Then you'll need to sbrk more from the OS.
> >
> > nmalloc handles this.
>
> Without any limitations? How do you overcome the problem of joining
> non-contiguous chunks? (Sorry, I don't have time to read the code and
> figure that out myself.)
If the various sbrk calls returned something non-contiguous (the
unexpected returns) nothing can join those. However everything in
a contiguous sbrk chunk, whether created by one or several sbrk
calls, will be rejoined when all components are freed. nmalloc
keeps track of adjacent allocations and rejoins them when freed.
Adjacent free blocks are always joined into one larger block. It
also attempts to do any new allocations from the free space list
on something close to best fit, and avoids sbrk calls as far as
possible.
The test code can do many allocations/frees/reallocs, and all
blocks are rejoined at exit, as proven by the debuggery output and
the tnmalloc driver. This was a fairly sensitive test that I
hadn't fouled up, and was not always true.
--
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
- Raw text -