Memory ``leaks'' in DEC servers
Jeff Michaud
michaud at decvax.dec.com
Fri Mar 9 06:01:28 AEST 1990
> 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> |
\--------------------------------------------------------------/
More information about the Comp.unix.ultrix
mailing list