Memory ``leaks'' in DEC servers

[Jeff Michaud]

> Presumably one could write a different free, that really frees the
> memory and returns it to the kernel via brk.  Version 19 of gnu emacs
> is supposed to have something that does this; emacs also has a problem
> of growing without bound since it keeps the entire file in memory.

	It's not that easy.  As Joel said, you also would need to
	do memory compaction.  You can't just use brk(2) because
	that sets the upper address for the data segment, and if
	there is any data still in use after the chunk of memory
	being free(3)'ed, someone's going to lose when they try
	to access the now non-existant memory.

	In order to easily do memory compaction, malloc would have
	to return a pointer to a pointer to the block of memory, and
	all references to the block of memory would have have to
	reference the block of memory through the indirect pointer.
	This way malloc can keep the indirect pointers table in
	the low part of the data segment, the rest of the heap
	can be compressed w/out anyone but malloc knowing.
	I believe this is how the Amiga and/or the Mac's memory
	allocators work?  Unfortunutly though, all of your application
	and all the libraries you use would have to use the new
	style memory allocator, or else if something else is using
	sbrk(2) to extend the data segment, then the new memory allocator
	can't safely reduce the data segment size.  Wouldn't it
	be nice it you could have holes in your data segment?
	(using shared memory is the closest you can get)

/--------------------------------------------------------------\
|Jeff Michaud    michaud at decwrl.dec.com  michaud at decvax.dec.com|
|DECnet-ULTRIX   #include <standard/disclaimer.h>              |
\--------------------------------------------------------------/