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

David T. Lewis lewis at mail.msen.com
Thu Aug 4 11:20:27 UTC 2005


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



More information about the Vm-dev mailing list