whay can't processes shrink as well as grow?

[Piercarlo Grandi]

On 3 Oct 90 22:59:43 GMT, ggm at brolga.cc.uq.oz.au (George Michaelson) said:

ggm> My understanding is that existing brk/sbrk/malloc in generic *nix
ggm> doesn't allow the process to shrink again once mem has been allocated.

It depends on what you mean, and the kernel you are working on...

ggm> Could somebody explain to a non-wizard what stops some method being
ggm> used to detect free mem pages or compress the heap such that memory
ggm> CAN be freed? I dont mean "for free" ie explain what would have to
ggm> be different in HOW malloc/alloc/sbrk/free work to get this behaviour.

Here you seem to imply that for you 'free' means 'freed at the malloc
level. Well, almost none of the C heap storage managers will lower the
break if this is possible. I have written (and posted to alt.sources) my
own malloc/free package that does lower the break if one frees a block
of store just under the break. It does not not to compaction of the
arena though.

There are C/C++ automatic storage reclaimers that use compacting garbage
collection; I do not know whether after compaction they lower the break,
if possible. If so, it would not be difficult to modify them to do so.

ggm> I'm expecting to be told that keeping back-pointers to entities using
ggm> allocated memory so you could dynamically update their position if
ggm> you'd compressed the heap is more pain than it's worth.

Read some papers on garbage collection, especially conservative g.c. in
C/C++. The sweeper of a g.c. reclaimer will in one way or another
simulate those backpointers.

ggm> If thats not the case, I see some attractive uses of grabbing 5-10
ggm> Mb of space, using it and then releasing it without having to exit.

Now there is a catch: even if your storage reclaimer detectes that a
block of memory just under the break has become free, and lowers the
break as a result, in many UNIX kernels this regrettably will not
release any pages to the kernel mmeory pool -- in some it will not even
invalidate page table entries beyond the break. This is probably because
so few C/C++ sotorage reclaimers bother to lower the break, so it is
perceived that actually shrinking the data and address space of a
process when the break is lowered is not worth its while.
--
Piercarlo "Peter" Grandi           | ARPA: pcg%uk.ac.aber.cs at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk