On Wed, Aug 03, 2005 at 11:00:12PM -0700, John M McIntosh wrote:
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.
Yes, that's right. But I've tested VMM versions with and without the constants (Tim put these in in the very next version of VMM as I recall), so that does not appear to be related to the problem. Also note that I'm building 32 bit VMs on 32 bit hardware for all the results I've reported.
So to summarize: The problem first appears as of VMMaker-tpr.22, which adds the johnmci & ar's GC instrumentation and weak pointer changes. The combination of VMMaker-tpr.21 plus ar's changes alone are not sufficient to trigger the problem. The problem shows up when running an image from ./dist3 (i.e. an image that has had the 64 bit image changes added), but not on other images such as Squeak3.9a-6472. All tests were done on 32 bit Intel Linux.
Dave
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 ======================================================================== ===