[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