Mail Archives: djgpp-workers/2002/05/17/10:53:05
> 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
- Raw text -