I recently got my nose rubbed in the fact that the memory heap
allocation has changed a lot. I'm sure it used to (from the variable
names and comments in my code) be that the parameter for '-memory:' was
the amount of headroom for the image that the vm should try to allocate.
Now the system is behaving as if that parameter is the _total_ memory to
allocate. It didn't really make any difference to me most of the time
because I have been running with 30Mb specified and that still left
plenty of room even with recent images. However, a user of my vm (yes,
Virginia, there are other Acorn users of Squeak out there) recently
spotted the problem.

Looking at the code for other platforms makes me think the change was a
side effect of the memory grow/shrink work from quite some time ago. I
think that in effect unix/w32/osx are relying upon the virtual memory &
grow facilities to let it all kind-of work it out for itself. However
I'm reasonably sure it could break if some small number were given for
'-memory:'. The symptom would most likely be a  'error("Insufficient
memory for this image") '.

Now I'm sure we could live with it either way but it does seem to me
that the sensible behaviour is for the 'memory parameter to be the spare
room allocated. It makes little sense to have people specify XMb and
then tell them 'guess again, that was not enough, sucker'. It's rude at
best. There are of course many, many machines without virtual memory
and/or with restrictive memory systems that are affected by this.

I propse that the simple and effective answer would be to change the
code in readImageFromFileHeapSizeStartingAt() to use:-
	heapSize = reserveExtraCHeapBytes(desiredHeapSize + dataSize,
extraVMMemory);
instead of the current:-
	heapSize = reserveExtraCHeapBytes(desiredHeapSize, extraVMMemory);

Does anyone have any thoughts on the matter? Any reasons why
specifying the total memory is better?

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: XER: Exclusive ERror