memory and VM issues (interp.c part 1 of 2 attached)
David T. Lewis
lewis at mail.msen.com
Thu Aug 4 20:20:26 UTC 2005
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.
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
> "Answer the size (in bytes) of an object pointer."
> "Smalltalk wordSize"
> ^[SmalltalkImage current vmParameterAt: 40] on: Error do: 
> "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
> 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
> 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
> 34 number of allocations done before current IGC/FGC
> 35 number of survivor objects after current IGC/FGC (read-
> 36 millisecond clock when current IGC/FGC completed (read-
> 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
More information about the Vm-dev