Tim Rowledge wrote:
> Expanding the memory allocation for Squeak should not be too difficult in most
> cases. For Unix, sbrk() ought to work. For Acorn, resizing the dynamic area is
> trivial.  I _think_ Mac's finally got some way to expand memory a while ago.
> Windows? Hmm, how about actually allocating a huge virtual space but pretending
> to the VM that you only have as much as the -memory param asked for. Then to
> expand, you just change that 'fake' boundary. The only trick that springs to
> mind is remembering to reset the size of the free chunk at the top of memory.
> 
> Shrinking object space wouldn't be much harder from the VM point of view,
> though I'm not sure whether the released memory would get back to the OS pool
> very efectively.

While sbrk would work its not at all ideal.  Its much better to use
mmap, and on Windows to use VirtualAlloc.  Don't yet know what to use on
Macs, but there's presumably some analogous function.  What these
functions do is map a chunk of address space and associated backing
store into the process address space.  The big advantage they have over
normal sbrk is one _can_ unmap the memory and backing store, shrinking
the process's footprint, and the memory _is_ released back to the OS
pool.

We added the ability to shrink memory in VW 2.5.2, and its now being
used in real server applications.

> The real problem with both expansion and shrinking is the policy decision of
> when to do it. VW has quite a complicated policy implemented in the image, with
> hooks to change it almost any way you want. IIRC almost no customer ever
> changed anything, they just complained that the default wasn't good enough for
> them!

In fact, we did a better policy for VisualWave.  VisualWave is an
extension to VW that allows applications to output HTML and hence be
used through web browsers.  In the web context one can have an arbitrary
number of users using the system, and the new memory policy was built to
provide more graceful degradation in the presence of large numbers of
users.

VW's memory policy really does need to get extended to automatically
shrink memory.  Its not that hard; one simply needs to provide
sufficient hysteresis.  But we can say that having an image level scheme
for controlling memory is a *good thing*.  We use MemoryPolicy and
ObjectMemory for the policy/mechanism split, and it works well; one can
plug-in new memory policies (e.g. for Wave) as required.

Essentially the VW memory policy does the following

- handle allocation failures (new & new: primitives that fail due to low
space) and decide whether to garbage collect or grow.  Currently there's
just a simple threshold below which growth is favoured, and above which
garbage collection is favoured.  But one can imagine more sophisticated
memory policies that interrogate the running app to decide what's
required

- handle low space and decide whether to run just the incremental gc, or
the full gc, or to interrupt the "current process".  Deciding what the
current process is is hard, and the default choice of the currently
active user-interface process isn't always the right choice.

I expect we'll add a post-GC action which will attempt to shrink memory
if the total amopunt of free space is greater than some minimum
freespace threshold.
_______________,,,^..^,,,_______________
Eliot Miranda, ParcPlace Aspect, ObjectShare