[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  
viewpoint.

primitivePerformAt: lookupClass
primitiveDoPrimitiveWithArgs

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

primitiveObjectAtPut
primitiveObjectAt

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

postGCAction
			(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?

incrementalGC
		
		(((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