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