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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

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

David T. Lewis
On Fri, Jul 29, 2005 at 01:03:31PM -0700, Tim Rowledge wrote:
> Could you try a 3.8-6665 image, SVN revision 1100, VMMaker38b4 combo?
> That is the last pre-64bit-fiddling build and should work ok. One thing
> we're a bit concerned with is the changes to GC/weak objects that got
> put in later.

OK, I spend some time hunting this down the hard way. I can't yet say
exactly what's wrong, but I think I've got it pretty well localized.

Executive summary: 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".

I don't know anything further at this point, but this should at least
narrow the search.

Here's my debugging log. A bit terse, but it will give you an idea of
some of the combinations that I tried.

- Dave

(CC to vm-dev list: This pertains to building a VM on my 32 bit Intel
Linux box from recent SVN and VMM code bases, following up on my
previous message "Problem building from latest SVN & VMM".)


----------------------------

Key:
  OK  -> does not exhibit the memory access bug (crash VM and/or debuggers in minimal image)
  NFG -> has the bug
  ?   -> not sure, gave up due to other problems

Test log (note: I closed in the the problem using SVN 1200 code base, varying VMM versions):

Platforms version               VMMaker version Result
-----------------               --------------- ------
./dist3                         ./dist3         OK

squeak-svn-source-SVN1100       VMMaker-tpr.15  ? needs sqMemoryAccess.h

squeak-svn-source-SVN1140       VMMaker-tpr.15  ? mismatch, lots of missing stuff
squeak-svn-source-SVN1140       VMMaker-tpr.20  ? parse error gnu-interp.c

squeak-svn-source-SVN1145       VMMaker-tpr.15  ? mismatch, lots of missing stuff
squeak-svn-source-SVN1145       VMMaker-tpr.20  ? parse error gnu-interp.c

squeak-svn-source-SVN1150       VMMaker-tpr.15  ? needs interp.h, parse error gnu-interp.c
squeak-svn-source-SVN1150       VMMaker-tpr.14  ? needs interp.h
squeak-svn-source-SVN1150       VMMaker-tpr.20  ? needs interp.h
squeak-svn-source-SVN1150       VMMaker-tpr.25  ? needs interp.h
squeak-svn-source-SVN1150       VMMaker-tpr.34  ? needs interp.h
squeak-svn-source-SVN1150       VMMaker-tpr.31  ? needs interp.h

squeak-svn-source-SVN1158       VMMaker-tpr.15  OK WRT bug, but has FilePlugin problem
squeak-svn-source-SVN1158       VMMaker-tpr.16  OK WRT bug, but has FilePlugin problem
squeak-svn-source-SVN1158       VMMaker-tpr.17  ? parse error in #sufficientSpaceToInstantiate:indexableSize:
squeak-svn-source-SVN1158       VMMaker-tpr.20  ? parse error in #sufficientSpaceToInstantiate:indexableSize:
squeak-svn-source-SVN1158       VMMaker-tpr.31  NFG
squeak-svn-source-SVN1158       VMMaker-tpr.33  ? undefined reference to `fetchWordofObject'

squeak-svn-source-SVN1165       VMMaker-tpr.15  OK WRT bug, but has FilePlugin problem
squeak-svn-source-SVN1165       VMMaker-tpr.16  OK WRT bug, but has FilePlugin problem
squeak-svn-source-SVN1165       VMMaker-tpr.31  NFG
squeak-svn-source-SVN1165       VMMaker-tpr.33  NFG
squeak-svn-source-SVN1165       VMMaker-tpr.34  ? undefined reference to `fetchWordofObject'
squeak-svn-source-SVN1180       VMMaker-tpr.35  ? undefined reference to `fetchWordofObject'
squeak-svn-source-SVN1180       VMMaker-tpr.37  ? undefined reference to `fetchWordofObject'

squeak-svn-source-SVN1200       VMMaker-tpr.16  OK WRT bug, but has FilePlugin problem
squeak-svn-source-SVN1200       VMMaker-tpr.20  OK, but parse error in #sufficientSpaceToInstantiate:indexableSize:
squeak-svn-source-SVN1200       VMMaker-tpr.21  ==> OK, but has FilePlugin problem plus parse error in #sufficientSpaceToInstantiate:indexableSize:
squeak-svn-source-SVN1200       VMMaker-tpr.22  ==> NFG, plus has FilePlugin problem plus parse error in #sufficientSpaceToInstantiate:indexableSize:
squeak-svn-source-SVN1200       VMMaker-tpr.23  NFG, plus has FilePlugin problem
squeak-svn-source-SVN1200       VMMaker-tpr.25  ? parse error in #sufficientSpaceToInstantiate:indexableSize:
squeak-svn-source-SVN1200       VMMaker-tpr.26  NFG
squeak-svn-source-SVN1200       VMMaker-tpr.28  NFG
squeak-svn-source-SVN1200       VMMaker-tpr.31  NFG
squeak-svn-source-SVN1200       VMMaker-tpr.37  NFG

squeak-svn-source-SVN1233       VMMaker-tpr.16  ? undefined reference to `fetchLong32ofObject'
squeak-svn-source-SVN1233       VMMaker-tpr.37  NFG


Reply | Threaded
Open this post in threaded view
|

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

timrowledge
Amongst other things I thnik this demonstrates that I need to think of
a decent way of correlating VMM releases (even down to the MC version
number?) with an SVN revision number. Bugger.

tim
--
Tim Rowledge, [hidden email], http://www.rowledge.org/tim
Useful random insult:- If you stand close enough to him, you can hear
the ocean.

Reply | Threaded
Open this post in threaded view
|

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

johnmci
In reply to this post by David T. Lewis
Ok, well my code and  Andreas' code were at one point separate.
I've attached Andreas' original changeset that dates from january and  
you should be
able to apply to a SVN 1100 pre 64 bit vmmaker setup. That should  
tell us if the
problem exists with his code.

Don't apply my GCInstrumentJMMImprovementsAR.1.cs.


On 31-Jul-05, at 7:43 PM, David T. Lewis wrote:

> On Fri, Jul 29, 2005 at 01:03:31PM -0700, Tim Rowledge wrote:
>
>> Could you try a 3.8-6665 image, SVN revision 1100, VMMaker38b4 combo?
>> That is the last pre-64bit-fiddling build and should work ok. One  
>> thing
>> we're a bit concerned with is the changes to GC/weak objects that got
>> put in later.
>>
>

--
========================================================================
===
John M. McIntosh <[hidden email]> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===



GCImprovements-ar.cs.zip (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

David T. Lewis
I tried ./dist3 image (i.e. VMM at whatever level it was at that
point), added GCImprovements-ar.cs, and built a VM that works fine.

I also tried loading GCImprovements-ar.cs after VMMaker-tpr.21.mcz,
but there are apparently a few other things to fix up in this
combination to produce a VM, so I can't really draw any conclusions
from this. But at this point the changes in GCImprovements-ar.cs
do not appear to be the source of the problem.

Dave

On Sun, Jul 31, 2005 at 11:48:30PM -0700, John M McIntosh wrote:

> Ok, well my code and  Andreas' code were at one point separate.
> I've attached Andreas' original changeset that dates from january and  
> you should be
> able to apply to a SVN 1100 pre 64 bit vmmaker setup. That should  
> tell us if the
> problem exists with his code.
>
> Don't apply my GCInstrumentJMMImprovementsAR.1.cs.
>
>
> On 31-Jul-05, at 7:43 PM, David T. Lewis wrote:
>
> > On Fri, Jul 29, 2005 at 01:03:31PM -0700, Tim Rowledge wrote:
> >
> >> Could you try a 3.8-6665 image, SVN revision 1100, VMMaker38b4 combo?
> >> That is the last pre-64bit-fiddling build and should work ok. One  
> >> thing
> >> we're a bit concerned with is the changes to GC/weak objects that got
> >> put in later.
> >>
> >

Reply | Threaded
Open this post in threaded view
|

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

David T. Lewis
In reply to this post by johnmci
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


Reply | Threaded
Open this post in threaded view
|

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

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


Reply | Threaded
Open this post in threaded view
|

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

David T. Lewis
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 <[hidden email]> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ========================================================================
> ===

Reply | Threaded
Open this post in threaded view
|

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

johnmci
Ok, perhaps you can summarize.

Are you saying if you take a 3.8 base image then apply a tpr.21 and  
build a VM that it works fine with the 3.8 base image?

And If you take Ian's ./dist3 image and run that then it fails using  
the new VM?

I will note that the call to get VMMparameter data has different  
slots from the one Ian originally submitted.
You should check that the ./dist3 image has

wordSize
     "Answer the size (in bytes) of an object pointer."
     "Smalltalk wordSize"

     ^[SmalltalkImage current vmParameterAt: 40] on: Error do: [4]


primitiveVMParameter
     "Behaviour depends on argument count:
         0 args:    return an Array of VM parameter values;
         1 arg:    return the indicated VM parameter;
         2 args:    set the VM indicated parameter.
     VM parameters are numbered as follows:
         1    end of old-space (0-based, read-only)
         2    end of young-space (read-only)
         3    end of memory (read-only)
         4    allocationCount (read-only)
         5    allocations between GCs (read-write)
         6    survivor count tenuring threshold (read-write)
         7    full GCs since startup (read-only)
         8    total milliseconds in full GCs since startup (read-only)
         9    incremental GCs since startup (read-only)
         10    total milliseconds in incremental GCs since startup  
(read-only)
         11    tenures of surving objects since startup (read-only)
         12-20 specific to the translating VM
         21    root table size (read-only)
         22    root table overflows since startup (read-only)
         23    bytes of extra memory to reserve for VM buffers,  
plugins, etc.
         24    memory threshold above which shrinking object memory (rw)
         25    memory headroom when growing object memory (rw)
         26  interruptChecksEveryNms - force an ioProcessEvents every  
N milliseconds, in case the image  is not calling getNextEvent often  
(rw)
         27    number of times mark loop iterated for current IGC/FGC  
(read-only) includes ALL marking
         28    number of times sweep loop iterated  for current IGC/
FGC (read-only)
         29    number of times make forward loop iterated for current  
IGC/FGC (read-only)
         30    number of times compact move loop iterated for current  
IGC/FGC (read-only)
         31    number of grow memory requests (read-only)
         32    number of shrink memory requests (read-only)
         33    number of root table entries used for current IGC/FGC  
(read-only)
         34    number of allocations done before current IGC/FGC  
(read-only)
         35    number of survivor objects after current IGC/FGC (read-
only)
         36  millisecond clock when current IGC/FGC completed (read-
only)
         37  number of marked objects for Roots of the world, not  
including Root Table entries for current IGC/FGC (read-only)
         38  milliseconds taken by current IGC  (read-only)
         39  Number of finalization signals for Weak Objects pending  
when current IGC/FGC completed (read-only)
         40 BytesPerWord for this image



On 4-Aug-05, at 4:20 AM, David T. Lewis wrote:

> 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
>
>
>

--
========================================================================
===
John M. McIntosh <[hidden email]> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===


Reply | Threaded
Open this post in threaded view
|

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

David T. Lewis
All the tests that I did started with the ./dist3 image. The various
versions of VMM were loaded into that base image, and the platforms
sources were of course separately downloaded from the Subversion
server. In all cases, the ./src tree was generated by a VmMakerTool
running in the dist3 based image.

If the image and the VM disagree as to the index of the VM parameter
for word size, I can certainly imagine that this would be a problem.
I'll check it out when I get home.

Thanks,

Dave

On Thu, Aug 04, 2005 at 09:50:18AM -0700, John M McIntosh wrote:

> Ok, perhaps you can summarize.
>
> Are you saying if you take a 3.8 base image then apply a tpr.21 and  
> build a VM that it works fine with the 3.8 base image?
>
> And If you take Ian's ./dist3 image and run that then it fails using  
> the new VM?
>
> I will note that the call to get VMMparameter data has different  
> slots from the one Ian originally submitted.
> You should check that the ./dist3 image has
>
> wordSize
>      "Answer the size (in bytes) of an object pointer."
>      "Smalltalk wordSize"
>
>      ^[SmalltalkImage current vmParameterAt: 40] on: Error do: [4]
>
>
> primitiveVMParameter
>      "Behaviour depends on argument count:
>          0 args:    return an Array of VM parameter values;
>          1 arg:    return the indicated VM parameter;
>          2 args:    set the VM indicated parameter.
>      VM parameters are numbered as follows:
>          1    end of old-space (0-based, read-only)
>          2    end of young-space (read-only)
>          3    end of memory (read-only)
>          4    allocationCount (read-only)
>          5    allocations between GCs (read-write)
>          6    survivor count tenuring threshold (read-write)
>          7    full GCs since startup (read-only)
>          8    total milliseconds in full GCs since startup (read-only)
>          9    incremental GCs since startup (read-only)
>          10    total milliseconds in incremental GCs since startup  
> (read-only)
>          11    tenures of surving objects since startup (read-only)
>          12-20 specific to the translating VM
>          21    root table size (read-only)
>          22    root table overflows since startup (read-only)
>          23    bytes of extra memory to reserve for VM buffers,  
> plugins, etc.
>          24    memory threshold above which shrinking object memory (rw)
>          25    memory headroom when growing object memory (rw)
>          26  interruptChecksEveryNms - force an ioProcessEvents every  
> N milliseconds, in case the image  is not calling getNextEvent often  
> (rw)
>          27    number of times mark loop iterated for current IGC/FGC  
> (read-only) includes ALL marking
>          28    number of times sweep loop iterated  for current IGC/
> FGC (read-only)
>          29    number of times make forward loop iterated for current  
> IGC/FGC (read-only)
>          30    number of times compact move loop iterated for current  
> IGC/FGC (read-only)
>          31    number of grow memory requests (read-only)
>          32    number of shrink memory requests (read-only)
>          33    number of root table entries used for current IGC/FGC  
> (read-only)
>          34    number of allocations done before current IGC/FGC  
> (read-only)
>          35    number of survivor objects after current IGC/FGC (read-
> only)
>          36  millisecond clock when current IGC/FGC completed (read-
> only)
>          37  number of marked objects for Roots of the world, not  
> including Root Table entries for current IGC/FGC (read-only)
>          38  milliseconds taken by current IGC  (read-only)
>          39  Number of finalization signals for Weak Objects pending  
> when current IGC/FGC completed (read-only)
>          40 BytesPerWord for this image
>
>
>
> On 4-Aug-05, at 4:20 AM, David T. Lewis wrote:
>
> > 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
> >
> >
> >
>
> --
> ========================================================================
> ===
> John M. McIntosh <[hidden email]> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ========================================================================
> ===

Reply | Threaded
Open this post in threaded view
|

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

timrowledge

On 4-Aug-05, at 1:20 PM, David T. Lewis wrote:

> All the tests that I did started with the ./dist3 image. The various
> versions of VMM were loaded into that base image, and the platforms
> sources were of course separately downloaded from the Subversion
> server. In all cases, the ./src tree was generated by a VmMakerTool
> running in the dist3 based image.

I can imagine all sorts of potential problems with loading that stuff
over an image with an earlier variant preloaded.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim


Reply | Threaded
Open this post in threaded view
|

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

David T. Lewis
In reply to this post by johnmci

Bingo. But good grief, Charlie Brown.

The image looks at vmParameterAt: 27, but Interpreter>>primitiveVMParameter puts the parameter in slot 40.

The assignment of slot 27 in the image is from the ikp changes of 3/26/2005 (i.e. the ./dist3 image, or the VMM38b4-64bit-image1-ikp.1.cs change set).

The actual primitive puts the Smalltalk word size in VM parameter 40. This would be from any version of VMM since VMMaker-tpr.22. Prior to this (VMMaker-tpr.21 and earlier), the slot assignment is 27.

If an image running on a recent VM asks for the value of vmParameterAt: 27, it is going to get the "number of mark loop iterated for current IGC/FGC (read-only) includes ALL marking". This is an interesting value, but perhaps not an optimal thing to use as the wordSize for object memory.

If I change SystemDictionary>>wordSize to use vmParameter at: 40, then all is well.

So there must be some image side update to Dan's work that is supposed to go along with the change from VMMaker-tpr.21 to VMMaker-tpr.22. Actually it's just the small update to SystemDictionary>>wordSize, but who knows if I'm missing something else. My guess would be that it's something that was included in the image side part of your (John's) object memory instrumentation that just has not been coordinated with the VMM side?

Thanks to Tim and John for the help; this lays the mystery to rest.

Dave


On Thu, Aug 04, 2005 at 09:50:18AM -0700, John M McIntosh wrote:

> Ok, perhaps you can summarize.
>
> Are you saying if you take a 3.8 base image then apply a tpr.21 and  
> build a VM that it works fine with the 3.8 base image?
>
> And If you take Ian's ./dist3 image and run that then it fails using  
> the new VM?
>
> I will note that the call to get VMMparameter data has different  
> slots from the one Ian originally submitted.
> You should check that the ./dist3 image has
>
> wordSize
>      "Answer the size (in bytes) of an object pointer."
>      "Smalltalk wordSize"
>
>      ^[SmalltalkImage current vmParameterAt: 40] on: Error do: [4]
>
>
> primitiveVMParameter
>      "Behaviour depends on argument count:
>          0 args:    return an Array of VM parameter values;
>          1 arg:    return the indicated VM parameter;
>          2 args:    set the VM indicated parameter.
>      VM parameters are numbered as follows:
>          1    end of old-space (0-based, read-only)
>          2    end of young-space (read-only)
>          3    end of memory (read-only)
>          4    allocationCount (read-only)
>          5    allocations between GCs (read-write)
>          6    survivor count tenuring threshold (read-write)
>          7    full GCs since startup (read-only)
>          8    total milliseconds in full GCs since startup (read-only)
>          9    incremental GCs since startup (read-only)
>          10    total milliseconds in incremental GCs since startup  
> (read-only)
>          11    tenures of surving objects since startup (read-only)
>          12-20 specific to the translating VM
>          21    root table size (read-only)
>          22    root table overflows since startup (read-only)
>          23    bytes of extra memory to reserve for VM buffers,  
> plugins, etc.
>          24    memory threshold above which shrinking object memory (rw)
>          25    memory headroom when growing object memory (rw)
>          26  interruptChecksEveryNms - force an ioProcessEvents every  
> N milliseconds, in case the image  is not calling getNextEvent often  
> (rw)
>          27    number of times mark loop iterated for current IGC/FGC  
> (read-only) includes ALL marking
>          28    number of times sweep loop iterated  for current IGC/
> FGC (read-only)
>          29    number of times make forward loop iterated for current  
> IGC/FGC (read-only)
>          30    number of times compact move loop iterated for current  
> IGC/FGC (read-only)
>          31    number of grow memory requests (read-only)
>          32    number of shrink memory requests (read-only)
>          33    number of root table entries used for current IGC/FGC  
> (read-only)
>          34    number of allocations done before current IGC/FGC  
> (read-only)
>          35    number of survivor objects after current IGC/FGC (read-
> only)
>          36  millisecond clock when current IGC/FGC completed (read-
> only)
>          37  number of marked objects for Roots of the world, not  
> including Root Table entries for current IGC/FGC (read-only)
>          38  milliseconds taken by current IGC  (read-only)
>          39  Number of finalization signals for Weak Objects pending  
> when current IGC/FGC completed (read-only)
>          40 BytesPerWord for this image
>
>
>
> On 4-Aug-05, at 4:20 AM, David T. Lewis wrote:
>
> > 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
> >
> >
> >
>
> --
> ========================================================================
> ===
> John M. McIntosh <[hidden email]> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ========================================================================
> ===

Reply | Threaded
Open this post in threaded view
|

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

johnmci
Ah, well Ian was making changes to code that VMMaker manages, Andreas  
was making changes, and I was making changes. (Let alone Tim)
These where all combined into various versions of VMMaker.tpr.xx as  
official combined (somewhat tested) sync points into various versions  
of the official images.
So by working with Ian's private ./dist3 image you worked with an  
image out of sync with the VM that contained things the Image cared  
about.

I'll note the official image only seems to look at wordSize for  
deciding if it should build a 32 versus 64 bit VM in VMMaker
So what does the ./dist3 image use wordSize for?


On 4-Aug-05, at 7:57 PM, David T. Lewis wrote:

>
> Bingo. But good grief, Charlie Brown.
>
> The image looks at vmParameterAt: 27, but  
> Interpreter>>primitiveVMParameter puts the parameter in slot 40.
>
> The assignment of slot 27 in the image is from the ikp changes of  
> 3/26/2005 (i.e. the ./dist3 image, or the VMM38b4-64bit-image1-ikp.
> 1.cs change set).
>
> The actual primitive puts the Smalltalk word size in VM parameter  
> 40. This would be from any version of VMM since VMMaker-tpr.22.  
> Prior to this (VMMaker-tpr.21 and earlier), the slot assignment is 27.
>
> If an image running on a recent VM asks for the value of  
> vmParameterAt: 27, it is going to get the "number of mark loop  
> iterated for current IGC/FGC (read-only) includes ALL marking".  
> This is an interesting value, but perhaps not an optimal thing to  
> use as the wordSize for object memory.
>
> If I change SystemDictionary>>wordSize to use vmParameter at: 40,  
> then all is well.
>
> So there must be some image side update to Dan's work that is  
> supposed to go along with the change from VMMaker-tpr.21 to VMMaker-
> tpr.22. Actually it's just the small update to  
> SystemDictionary>>wordSize, but who knows if I'm missing something  
> else. My guess would be that it's something that was included in  
> the image side part of your (John's) object memory instrumentation  
> that just has not been coordinated with the VMM side?
>
> Thanks to Tim and John for the help; this lays the mystery to rest.
>
> Dave
>
>
> On Thu, Aug 04, 2005 at 09:50:18AM -0700, John M McIntosh wrote:
>
>> Ok, perhaps you can summarize.
>>
>> Are you saying if you take a 3.8 base image then apply a tpr.21 and
>> build a VM that it works fine with the 3.8 base image?
>>
>> And If you take Ian's ./dist3 image and run that then it fails using
>> the new VM?
>>
>> I will note that the call to get VMMparameter data has different
>> slots from the one Ian originally submitted.
>> You should check that the ./dist3 image has
>>
>> wordSize
>>      "Answer the size (in bytes) of an object pointer."
>>      "Smalltalk wordSize"
>>
>>      ^[SmalltalkImage current vmParameterAt: 40] on: Error do: [4]
>>
>>
>> primitiveVMParameter
>>      "Behaviour depends on argument count:
>>          0 args:    return an Array of VM parameter values;
>>          1 arg:    return the indicated VM parameter;
>>          2 args:    set the VM indicated parameter.
>>      VM parameters are numbered as follows:
>>          1    end of old-space (0-based, read-only)
>>          2    end of young-space (read-only)
>>          3    end of memory (read-only)
>>          4    allocationCount (read-only)
>>          5    allocations between GCs (read-write)
>>          6    survivor count tenuring threshold (read-write)
>>          7    full GCs since startup (read-only)
>>          8    total milliseconds in full GCs since startup (read-
>> only)
>>          9    incremental GCs since startup (read-only)
>>          10    total milliseconds in incremental GCs since startup
>> (read-only)
>>          11    tenures of surving objects since startup (read-only)
>>          12-20 specific to the translating VM
>>          21    root table size (read-only)
>>          22    root table overflows since startup (read-only)
>>          23    bytes of extra memory to reserve for VM buffers,
>> plugins, etc.
>>          24    memory threshold above which shrinking object  
>> memory (rw)
>>          25    memory headroom when growing object memory (rw)
>>          26  interruptChecksEveryNms - force an ioProcessEvents every
>> N milliseconds, in case the image  is not calling getNextEvent often
>> (rw)
>>          27    number of times mark loop iterated for current IGC/FGC
>> (read-only) includes ALL marking
>>          28    number of times sweep loop iterated  for current IGC/
>> FGC (read-only)
>>          29    number of times make forward loop iterated for current
>> IGC/FGC (read-only)
>>          30    number of times compact move loop iterated for current
>> IGC/FGC (read-only)
>>          31    number of grow memory requests (read-only)
>>          32    number of shrink memory requests (read-only)
>>          33    number of root table entries used for current IGC/FGC
>> (read-only)
>>          34    number of allocations done before current IGC/FGC
>> (read-only)
>>          35    number of survivor objects after current IGC/FGC  
>> (read-
>> only)
>>          36  millisecond clock when current IGC/FGC completed (read-
>> only)
>>          37  number of marked objects for Roots of the world, not
>> including Root Table entries for current IGC/FGC (read-only)
>>          38  milliseconds taken by current IGC  (read-only)
>>          39  Number of finalization signals for Weak Objects pending
>> when current IGC/FGC completed (read-only)
>>          40 BytesPerWord for this image
>>
>>
>>
>> On 4-Aug-05, at 4:20 AM, David T. Lewis wrote:
>>
>>
>>> 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
>>>
>>>
>>>
>>>
>>
>> --
>> =====================================================================
>> ===
>> ===
>> John M. McIntosh <[hidden email]> 1-800-477-2659
>> Corporate Smalltalk Consulting Ltd.  http://
>> www.smalltalkconsulting.com
>> =====================================================================
>> ===
>> ===
>>
>
>

--
========================================================================
===
John M. McIntosh <[hidden email]> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===


Reply | Threaded
Open this post in threaded view
|

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

David T. Lewis
On Thu, Aug 04, 2005 at 10:47:23PM -0700, John M McIntosh wrote:

> Ah, well Ian was making changes to code that VMMaker manages, Andreas  
> was making changes, and I was making changes. (Let alone Tim)
> These where all combined into various versions of VMMaker.tpr.xx as  
> official combined (somewhat tested) sync points into various versions  
> of the official images.
> So by working with Ian's private ./dist3 image you worked with an  
> image out of sync with the VM that contained things the Image cared  
> about.
>
> I'll note the official image only seems to look at wordSize for  
> deciding if it should build a 32 versus 64 bit VM in VMMaker
> So what does the ./dist3 image use wordSize for?
It's used in CompiledMethod>>initialPC, which is:

initialPC
  "Answer the program counter for the receiver's first bytecode."

  ^ (self numLiterals + 1) * Smalltalk wordSize + 1

There are other image side changes as well in Dan's image side
updates. They are available on the "64 bit Unix Squeak" web site
http://squeak.hpl.hp.com/squeak64/, which says that they are a
required part of 64 bit Squeak.

Since the image side changes are required for 64 bit Squeak, and
also work for 32 bit Squeak, I guess I just assumed that the
vm-dev folks were all using them.

It sounds like somebody needs to "adopt" Dan's change sets and
either get them into the mainstream images, or maintain them as
a SqueakMap package until they are incorporated in the image.
And also of course to make that one small change to
SystemDictionary>>wordSize to bring it back into sync with
the more recent VMMaker code.

I'm attaching the trival change just so it does not get lost,
with CC to Dan and Ian.

Dave


WordSizeVMParameterFix-dtl.1.cs (611 bytes) Download Attachment