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