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

[John M McIntosh]

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