Hi Chris, Hi All,

On Mon, Dec 29, 2014 at 3:18 PM, Chris Muller <asqueaker@gmail.com> wrote:

Hi Eliot, today I was working and remembered that you asked me to post
a reminder request about the ability to restrict a Spur VM's memory
expansion via -mmap or -memory parameters.

It can be useful when you want to prevent an image from being able to
consume more resources from the machine than you want.

This is interesting.  I just took a look at implementing this and a few issues came up.

First is how frustrating the sprawling platform subsystem is.  The VW VM has a ell-defined set of interfaces between platform-specific code and the broader VM, which help guide the design and provide regularity across platforms.  This kind of thing only exists in some places in the Squeak VM.  And specifying memory is one example where its conspicuously absent. So in our VM there is a different variable for holding the max heap size on each platform:

Mac: usqLong gMaxHeapSize
Plan9/Unix: long extraMemory
RiscOS: long objectHeadroom
win32: DWORD dwMemorySize

Note that the lack of a defined interface makes room for bugs. "long" is clearly wrong. It must be an unsigned type to not restrict us to half the available memory.

Now in Spur I've reimplemented a smaller, common memory allocation interface for all platforms. So I could simply add a common variable and change code so that it reads e.g.

else if (argc > 1) {
if (!strcmp(argv[0], "-memory")) {  #if SPURVM
maxMemory = strtolbkm(argv[1]);
gMaxHeapSize = strtolbkm(argv[1]); #endif
return 2; }

But then I thought why not move the responsibility up to the image?  In Spur the only interface to growing memory is 
SmalltalkImage>>growMemoryByAtLeast: numBytes
"Grow memory by at least the requested number of bytes.
Primitive.  Essential. Fail if no memory is available."
<primitive: 180>
(numBytes isInteger and: [numBytes > 0]) ifTrue:
[OutOfMemory signal].
^self primitiveFailed

So that would be a place to introduce a MemoryPolicy class that could monitor memory from the VM via vmParameterAt: and be parameterisable e.g. by preferences, and then grow over time into something that can be controlled easily from the image.  What do you think?