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.
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]); #else 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?
On 05-01-2015, at 12:24 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Mac: usqLong gMaxHeapSize Plan9/Unix: long extraMemory RiscOS: long objectHeadroom win32: DWORD dwMemorySize
History; originally the memory allocation was purely the platform’s job and the only interface was the macro allocateMemoryMinimumImageFileHeaderSize which in bizarre turn used sqAllocateMemory unless it was previously defined. Yeah, I always thought it was stupid too. And I see that ‘memory’ is a usqInt in the trunk code, so ‘long’ etc really ought to have caused complaints.. .but C compilers… Oh, I see you have static char * allocateMemoryminimumimageFileheaderSize in gcc3x-cointerp.c (as of VMMaker.oscog-eem.951 anyway) and cast it to usqInt.
There’s lots of this stuff. As I imagine you’ve noticed. We should do better.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Debugger: A tool that substitutes afterthought for forethought.
vm-dev@lists.squeakfoundation.org