memory and VM issues (interp.c part 1 of 2 attached)
John M McIntosh
johnmci at smalltalkconsulting.com
Fri Aug 5 05:47:23 UTC 2005
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 <johnmci at smalltalkconsulting.com> 1-800-477-2659
>> Corporate Smalltalk Consulting Ltd. http://
>> www.smalltalkconsulting.com
>> =====================================================================
>> ===
>> ===
>>
>
>
--
========================================================================
===
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
mailing list