All:

Several times lately I've run into low space conditions when, by error, I tried to allocate a huge chunk. Squeak goes into a *slow* loop on basicNew:.  Try:

	Array new: 2000000

I think that the allocation of a huge glob fails, the low space watcher is invoked, does some garbage collection, checks low space thresholds, and discovers that there is lots of space. So the low space watcher is reinstalled and the basicNew is retried and fails again, etc. The assumption is that memory is really getting low; the reality is that there is lots of memory but not enough to allocate 2000000*4 bytes.

I don't offhand see an easy fix in the low space watcher since the amount of memory requested is not available there; if it was, it would be easy. 

Another approach might be to fix up all basicNew: methods. See below just after signalLowSpace for an example. (The magic 4 obviously needs to be the actual allocation space for the element.)

Behavior>>new: anInteger 
	"Primitive. Answer an instance of the receiver (which is a class) with the 
	number of indexable variables specified by the argument, anInteger. Fail 
	if the class is not indexable or if the argument is not a positive Integer. 
	Essential. See Object documentation whatIsAPrimitive."

	<primitive: 71>
	self isVariable ifFalse: [
		self error: self printString, ' cannot have variable sized instances'].
	(anInteger isInteger and: [anInteger >= 0]) ifTrue: [
		"arg okay; space must be low"
		Smalltalk signalLowSpace.
		Smalltalk bytesLeft - Smalltalk lowSpaceThreshold <= (anInteger*4) ifTrue: [
			self error: 'Object is too big.' ].
		^ self basicNew: anInteger  "retry if user proceeds"
	].
	self primitiveFailed

Dave
_______________________________
David N. Smith
IBM T J Watson Research Center
Hawthorne, NY
_______________________________
Any opinions or recommendations
herein are those of the author  
and not of his employer.