whay can't processes shrink as well as grow?

George Michaelson ggm at brolga.cc.uq.oz.au
Thu Oct 11 12:55:19 AEST 1990


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 at cc.uq.oz.au                     Phone: +61 7 377 4079
  Postal: George Michaelson, Prentice Computer Centre
          The University of Queensland, St Lucia, QLD Australia 4067. 



More information about the Comp.unix.internals mailing list