Dynamic system memory use

Lex Spoon lex at cc.gatech.edu
Fri Feb 1 05:55:22 UTC 2002


Tim Rowledge <tim at sumeru.stanford.edu> wrote:
> Squeak can increase the memory it uses if the OS supports a suitable
> method of extending the original allocation - or potentially making a
> new larger allocation and copying the entire object memory across and
> swizzling all the pointers. See the macros
>     #define sqGrowMemoryBy(oldLimit, delta) oldLimit
>     #define sqShrinkMemoryBy(oldLimit, delta) oldLimit
>     #define sqMemoryExtraBytesLeft(includingSwap) 0
> in sq.h and their uses.

Unfortunately, these functions are hard to implement.  They expect the
heap to be reallocated *in place*, and more importantly, they expect the
heap to stay as one contiguous segment.  realloc() could probably be
made to work, but it's still going to be difficult on the underlying OS,
simply because realloc-ing hundreds of megs will make the 4 gigs of
32-bit addressable space start running out!

I don't know what is being done on the Windows and MacOS ports to
support these.  On Unix, all I could think of is to allocate a huge
amount of space using mmap, and then not touch it until it's needed. 
This works for allocation.  For deallocation, munmap can be used,
followed by an immediate mmap.  Unfortunately, there is no real
guarantee that the second mmap is going to work, which would mean the
system suddenly has a very small amount of free heap space!


> One of the classic problems with trying to extend or reduce memory usage
> is thrashing; you do all the work of getting more or releasing some and
> - wham, you need to reverse and do the opposite. I did a version once
> that tried a hysterisis approach of never releasing more than one
> previously added segment jst in case and that worked quite well in the
> seriously memory constrained environment in which it lived (1Mb ram
> total on the machine).

Was this work for Squeak?!

A segmented allocater would be a lot easier on the underlying platform. 
Every platform has malloc() and free().  Not every platform has
"allocate and leave plenty of space after the end()" and "remember that
area I allocated?  allocate some more() ".

Then again, in practice it's not a big deal.  Normally a default of 30m
or so is plenty.  Furthermore, the memory is usually not wasted: Unices
tend to not allocate real RAM (or often even real swap space) until you
actually try to use your memory.  And if you need more memory, then you
can typically specify a few hundred megs and be fine.  It should be rare
to have very many such processes on a single computer.


-Lex



More information about the Squeak-dev mailing list