[Vm-dev] Re: VM patches for oop comparison and usqInt declarations

John M McIntosh johnmci at smalltalkconsulting.com
Fri Jun 8 21:07:35 UTC 2007

Ok, I build a new VM using these changes then poked about  and  
wondered about the following compares as below.

Also did some tests, by altering mmap I ran the VM at the 3GB  
boundary, that seemed to work ok.

I then attempted to run it at the 1.5 GB boundary using a memory size of

641,732,608  at the 1.5GB boundary

The basic image (a 3.5 image) started at 20MB. I then allocated 450  
mb of memory and did macro-benchmarks

| suck |
suck := OrderedCollection new.
	suck add: (ByteArray new: 1024*1024*450).
100 timesRepeat: [
	Smalltalk macroBenchmarks.
	suck add: (ByteArray new: 1024*1024*1).
	Transcript show: Smalltalk garbageCollectMost;cr.
	Transcript show: Smalltalk garbageCollect;cr].

However when young space approached, when over, inbetween, whatever  
the 2GB boundary the VM core dumped.
I was unable to printAllStacks(). I'll look a bit further and put  
some more debugging in to see if I can determine why.

- questionable? signed/unsigned compares at least from the compiler  

primitivePerformAt: lookupClass

		self success: (self stackPointerIndex + arraySize) < cntxSize].


		self success: index <= ((self literalCountOf: thisReceiver) +  

			(self sizeOfFree: freeBlock) > shrinkThreshold
		Ok here if the size of the free > 2GB that is an issue
		Also shrinkThreshold is signed, but should it be?

		(((self sizeOfFree: freeBlock) < growHeadroom)

I think you need to check usage of sizeOfFree:  it could be > 2GB,  
very unlikely, but one never knows

On May 27, 2007, at 6:22 AM, David T. Lewis wrote:

> On Wed, Apr 25, 2007 at 06:59:49AM -0400, David T. Lewis wrote:
>> The attached zip contains six change sets and an update for  
>> sqMemoryAccess.h.
>> The changes are intended to resolve problems with oop variable  
>> declarations
>> and comparison operations that may occur on platforms that assign  
>> object
>> memory to high virtual memory address values.
> Can anyone confirm whether these changes are producing the intended
> results, i.e. a system that used to crash with >2GB oop issues, and
> no longer crashes after applying the changes? I don't have any Squeak
> platform that exhibits the problem, so so I can't confirm whether or
> not the problem is actually resolved.
> Thanks,
> Dave

John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com

More information about the Vm-dev mailing list