Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.unix.internals Subject: Re: whay can't processes shrink as well as grow? Message-ID: Date: 10 Oct 90 21:26:00 GMT References: <1990Oct3.225943.4691@brolga.cc.uq.oz.au> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 46 Nntp-Posting-Host: odin In-reply-to: ggm@brolga.cc.uq.oz.au's message of 3 Oct 90 22:59:43 GMT On 3 Oct 90 22:59:43 GMT, ggm@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@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk