Hi all. i’ve been wanting to send this for a while but haven’t been receiving the squeak lists, so i wasn’t sure if it might have been discussed as part of the low-memory-watcher discussion. i was working to get my subscription to the mailing working to no avail. however, i have reviewed the archives and it doesn’t appear that this aspect has been raised. btw, i finally registered with my gmail address instead, so i’m getting the list again.
since i’m seeing some traffic on lowSpaceWatcher, i thought i’d send this along.
we are running an ancient swiki server (squeak 3.7, swiki 1.5—same as wiki.squeak.org, i guess) and we will occasionally have it go into a low space condition displaying the “space is low” debug window even though the Memory Usage Morph indicates there is a reasonable amount of memory available. in addition i don’t seem to be able to escape out of the “space is low” debug window once this happens.
i’m not asking for a fix to an old Squeak version, just wondering what might be a reasonable approach here and whether the insights might still inform current systems.
in looking at what might cause this, it seems that this is triggered when a “new:” (rather “basicNew:”) primitive fails. i understand that the VM primitive only returns success or failure, so the reason why it fails is assumed to be low memory, thus the low space condition trigger.
of course, i haven’t been able to get this to happen in production since i started looking into it, so i don’t have any debug traces to look at and trace back the real cause.
so i tried Array new: <a very large number> and was able to trigger the condition, and indeed the memory variables still show space available (Smalltalk bytesLeft is still much greater than Smalltalk lowSpaceThreshold), which would seem to indicate that the issue is not “low memory” but “impossible request” (i know this is somewhat of a distinction without a difference, since if a new: request fails it is effectively an “impossible request” but the difference i see is that the request is much larger than is usual in the system, and this occurs when memoryLeft is much greater than lowSpaceThreshold, i.e., space is NOT low)
i imagine that when this happens within a swiki/comanche request, it is caused by someone trying to overflow a buffer or something using http. when i do it from a workspace, the "space is low” debug window is triggered, but i am able to abandon it.
what i wonder is whether some other error should be raised in this case rather than signalling low memory. if one were to check the state of the memory variables before signalling "out of memory” it might avoid this. but i’m not sure what error should be raised in this case. i guess some report of an “impossible” request in the web log might be useful.
i haven’t been able to replicate this in newer versions of squeak with a more robust memory handling system, since it seems to rely more on virtual memory than on some sort of fixed allocation. but the code appears to do the same thing if “basicNew:” fails, so perhaps insights might be applicable here although it seems very difficult to trigger in new systems. (of course, i don’t think anyone has ported the swiki to newer systems?)
anyway, your insights would be appreciated.
hal