X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Date: Fri, 17 May 2002 11:59:08 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp-workers AT delorie DOT com
Message-Id: <4331-Fri17May2002115908+0300-eliz@is.elta.co.il>
X-Mailer: emacs 21.2.50 (via feedmail 8 I) and Blat ver 1.8.9
In-reply-to: <3CE3FF64.E0F0D953@yahoo.com> (message from CBFalconer on Thu, 16
	May 2002 14:50:13 -0400)
Subject: Re: emacs under w2k
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1020516075834 DOT 13145D-100000 AT is> <3CE3990C DOT 308C92EC AT yahoo DOT com> <1225-Thu16May2002182200+0300-eliz AT is DOT elta DOT co DOT il> <3CE3FF64 DOT E0F0D953 AT yahoo DOT com>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Thu, 16 May 2002 14:50:13 -0400
> From: CBFalconer <cbfalconer AT yahoo DOT com>
> > 
> > How do you overcome the problem of joining non-contiguous chunks?
> 
> If the various sbrk calls returned something non-contiguous (the
> unexpected returns) nothing can join those.

I didn't mean memory that was non-contiguous to begin with.  I meant
memory that was returned as contiguous by sbrk, but was then
subdivided into chunks by malloc, and became non-contiguous after
several allocations and deallocations.

> However everything in a contiguous sbrk chunk, whether created by
> one or several sbrk calls, will be rejoined when all components are
> freed.

The problem is precisely that not everything is deallocated when you
suddenly need a large chunk of memory.  Some Lisp objects are
short-lived, others tend to live for a long time before they die and
are freed by the garbage collector.  That's the reason for
fragmentation.

The only way to avoid the adverse effects of such fragmentation is to
relocate memory when you don't have a contiguous block large enough to
satisfy the request, but do have enough free memory in non-contiguous
chunks.  That's what the Emacs relocating allocator does, but that
cannot be done in a C library.

> 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.

I think the current libc version also does that, at least within the
bucket.