I think if you look the johnmci & ar's GC instrumentation and weak pointer changes do not consider the width 32 versus 64 and originally used hard coded numbers to indicate the size of a word or header. Later this was changed to use constants.
To confirm consider !ObjectMemory methodsFor: 'finalization' stamp: 'ar 1/18/2005 16:39'! finalizeReference: oop "During sweep phase we have encountered a weak reference. Check if its object has gone away (or is about to) and if so, signal a semaphore. " "Do *not* inline this in sweepPhase - it is quite an unlikely case to run into a weak reference" | weakOop oopGone chunk firstField lastField | self inline: false. firstField _ BaseHeaderSize + ((self nonWeakFieldsOf: oop) << 2). lastField _ self lastPointerOf: oop. firstField to: lastField by: 4 do: [:i |
where we do a to:by: with 4, or the shift (<<) by 2.
The VMMaker in beta that later shipped, what is the version?. change that I believe to !ObjectMemory methodsFor: 'finalization' stamp: 'JMM 4/13/2005 20:54'! finalizeReference: oop "During sweep phase we have encountered a weak reference. Check if its object has gone away (or is about to) and if so, signal a semaphore. " "Do *not* inline this in sweepPhase - it is quite an unlikely case to run into a weak reference" | weakOop oopGone chunk firstField lastField | self inline: false. firstField _ BaseHeaderSize + ((self nonWeakFieldsOf: oop) << ShiftForWord). lastField _ self lastPointerOf: oop. firstField to: lastField by: BytesPerWord do: [:i |
where as you see we use the ShiftForWord and the BytesPerWord
So if you are building a 64bit VM, and if the code you have says firstField to: lastField by: 4 do: [:i | then you are hosed. If the code does have the BytesPerWord, it is possible lurking in the changeset a missing change where we need to use some nemonic versus 2 or 4 or some other magic number that is affected when you go from 32 to 64.
On 3-Aug-05, at 6:49 PM, David T. Lewis wrote:
I've been trying to isolate this problem on my <red herring> 32 bit Intel Linux </red herring> system by looking for what changed in the VMM code and the SVN platforms tree, testing the resulting VMs with the 32 bit image from squeak.hpl.hp.com/squeak64/dist3/Squeak32-3.8g-6548.image.tar.gz.
The results so far can be summarized as:
The problem was introduced in VMM code as opposed to platforms code. It was introduced in the change from VMMaker-tpr.21 to VMMaker-tpr. 22. The VMMaker-tpr.22 change set contains "Merge in johnmci & ar's GC instrumentation and weak pointer changes".
Platforms version VMMaker version Result
squeak-svn-source-SVN1200 VMMaker-tpr.21 OK squeak-svn-source-SVN1200 VMMaker-tpr.22 NFG
But I discovered (entirely by accident) that I overlooked a rather large dimension of the problem. The bad (?) VM created from squeak-svn- source-SVN1200 and VMMaker-tpr.22 works just fine with an image that does not have the 64 bit changes installed. So now comparing the results from a Squeak32-3.8g-6548.image from the original ./dist3 distribution (image with 64 bit changes loaded) versus a "stock" Squeak image such as Squeak3.7-5989-basic.image or Squeak3.9a-6472.image, we have this:
Platforms version VMMaker version Image Result
squeak-svn-source-SVN1200 VMMaker-tpr.21 dist3/ Squeak32-3.8g-6548.image OK squeak-svn-source-SVN1200 VMMaker-tpr.22 dist3/ Squeak32-3.8g-6548.image NFG squeak-svn-source-SVN1200 VMMaker-tpr.21 Squeak3.7-5989- basic.image OK squeak-svn-source-SVN1200 VMMaker-tpr.22 Squeak3.7-5989- basic.image OK squeak-svn-source-SVN1200 VMMaker-tpr.21 Squeak3.9a-6472.image OK squeak-svn-source-SVN1200 VMMaker-tpr.22 Squeak3.9a-6472.image OK
Evidently the combination of the changes introduce in VMMaker-tpr. 22 with the changes that were added to the Squeak32-3.8g-6548 image in ./dist3, and maybe or maybe not in combination with a 32 bit Intel Linux platform, are what cause the problem to be present.
I have not tried any other experiments yet, but I thought I should report this in case anyone is losing sleep over the problem right now.
My next steps (but not tonight) will be to try adding some or all of VMM38b4-64bit-image1-ikp.1.cs, VMM38b4-64bit-image2-ikp.1.cs, and System-Tracing.2.cs to a "stock" image and see if one of them induces the problem when running on a "bad" VM built from squeak-svn-source- SVN1200 and VMMaker-tpr.22.
Dave
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===