memory and VM issues (interp.c part 1 of 2 attached)

[John M McIntosh]

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 at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===