Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!munnari.oz.au!brolga!ggm From: ggm@brolga.cc.uq.oz.au (George Michaelson) Newsgroups: comp.unix.internals Subject: Re: whay can't processes shrink as well as grow? Message-ID: <1990Oct11.025519.19255@brolga.cc.uq.oz.au> Date: 11 Oct 90 02:55:19 GMT References: <1990Oct3.225943.4691@brolga.cc.uq.oz.au> Organization: Prentice Computer Centre, The University of Queensland, Australia. Lines: 26 Thankyou for all the followups and individual emails. It looks as if there is no guaranteed method of achieving what I wanted, although on some systems there *are* ways of coming close if not all the way. modified malloc sounds closest in being simple to retrofit, and may offer benefit if slipped under existing programs, certainly if large single blocks of space are malloc'ed and freed. I dont think compaction sounds feasible short of a C++ approach providing it in the infrastructure, unless you are prepared to do ALL the ptr management yourself. If you have a way to model some data in a humungous space (eg trying to do data persistance by dumping memory to disk between process invokations) you're probably doing 1/2 of it already. I *did* try R'ing the FM in this area, and must say that on SunOS4.1 at least it is less than perspex clear on brk/sbrk behaviour, at least for anybody not well versed in system internals. Clearly an area fools like me are not meant to tread. Seems a shame, given programs which have transient need for large dynamic data areas but can then become vastly smaller again. What we get from the opsys is simple to implement, but also seems lacking in functionality. -george -- G.Michaelson Internet: G.Michaelson@cc.uq.oz.au Phone: +61 7 377 4079 Postal: George Michaelson, Prentice Computer Centre The University of Queensland, St Lucia, QLD Australia 4067.