X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Date: Fri, 17 May 2002 17:51:29 +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: <1225-Fri17May2002175128+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: <3CE4B60B.E68E28AB@yahoo.com> (message from CBFalconer on Fri, 17
	May 2002 03:49:31 -0400)
Subject: Re: Malloc/free DJGPP code
References: <10205161914 DOT AA17309 AT clio DOT rice DOT edu> <3CE41EB8 DOT 619484D9 AT yahoo DOT com> <9743-Fri17May2002100518+0300-eliz AT is DOT elta DOT co DOT il> <3CE4B60B DOT E68E28AB 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: Fri, 17 May 2002 03:49:31 -0400
> From: CBFalconer <cbfalconer AT yahoo DOT com>
> > 
> > Also, don't forget that there are other programs running on the same
> > box, at least if you run on Windows.  So returning unused memory to
> > the OS would be a Good Thing.
> 
> The problem is that you can't return a complete block to the
> system, because the internal allocation mechanism requires that
> something always be left over.  Once the unexpected sbrk is
> received the old block becomes completely available, and gets
> used.  Forcing saving of a final piece would also be wasteful.

Sorry, I don't understand what you mean.  Our sbrk allocates memory
from the DPMI host in 64KB chunks.  Let's say that malloc has detected
that a contiguous 64KB block at the top of the program's address space
has been freed in its entirety, and calls sbrk to return that block
to the DPMI host--what problems do you see with honoring that call?

> What you can do is reduce a sbrk block.  But once the system
> returns a noncontiguous chunk, which it is most likely to do if
> there are other processes

Actually, in many cases the chunks are contiguous.  Under the Unixy
sbrk algorithm, sbrk resizes the current memory allocated to the
process (rather than requesting an additional chunk of memory).  This
makes sure the program's memory is contiguous at all times, which is
what the Unixy sbrk is all about.

Most importantly, the gmalloc allocator used by Emacs already does all
the necessary processing to move the unused space to the end of the
program's data segment.  So supporting negative sbrk's will indeed
help there.  It is not uncommon for an Emacs session to need to create
a buffer for a multimegabyte file, then kill that buffer and never
need anything that big for quite a while.  The current behavior
whereby those megabytes stay reserved by the Emacs session is not
optimal.