Re: [Squeak-VMdev] Re: GC improvements

[Andreas R. <and...@gm...>]

Hi John,

Thanks, got it - the VM-dev list is just very slow. Some comments:

* Using TheGCSemaphore makes the VM unusable with older images due to splObj 
size mismatch - I'd want to change this to use an external semaphore index 
(this is what I used for "my" primitive) to be able to run 3.6 images on 3.8 
VMs.

* One of the truly important situations which is not covered in these 
measures is when we have to run multiple compaction cycles due to lack of 
forwarding blocks. I believe this has killed me in the past and taking GC 
stats should definitely include this tad of information (dunno how to 
measure to be honest...)

* The logic in incrementalGC for growing namely:

    (((self sizeOfFree: freeBlock) < growHeadroom) and:
        [(self fetchClassOf: (self splObj: TheGCSemaphore)) =
            (self splObj: ClassSemaphore)]) ifTrue:
        [growSize _  growHeadroom*3/2 - (self sizeOfFree: freeBlock)
         self growObjectMemory: growSize].

  looks odd. Questions:
      - What has TheGCSemaphore to do with growing?
      - Why do we grow when having less than growHeadroom space?
        (all we need here is enough space to accomodate the next round of 
allocations + IGC - I don't see a logic here)
      - Why is the grow size inconsistent with, e.g., 
sufficientSpaceAfterGC:?
      - Why do it all? :-)
        (no, quite seriously, I don't see what good the logic actually does)

* Measuring statMarkCount, statCompMoveCount, statSweepCount, statMkFwdCount 
etc. seem to be excessive - is there really any need to add extra 
instructions to these tight loops? I'd rather live without these insns in 
the midst of time-critical GC code.

Other than this it looks good. So I'd propose that:
a) We use "my" GC signaling code in order to keep the VMs compatible.
b) Add a counter for multiple compaction cycles (if we know how that is)
c) Either remove the growing code from IGC or add a comment explaining what 
the point of it is and why the parameters have been choosen the way they 
have been choosen
d) Get rid of of the counters in the inner loops of the GC code.

Opinions? (I'd be happy to integrate John's code on top of what I just 
posted)

Cheers,
  - Andreas

----- Original Message ----- 
From: "John M McIntosh" <jo...@sm...>
To: "Ian Piumarta" <ian...@hp...>; "Andreas Raab" 
<and...@gm...>
Cc: "Squeak VM Developers" <squ...@li...>; "Tim 
Rowledge" <ti...@su...>
Sent: Tuesday, January 18, 2005 8:32 PM
Subject: Re: [Squeak-VMdev] Re: GC improvements


> Well I tried to reply to the list, but that hasn't arrived yet.
>
> There is a primitive to set the GC semaphore,
> some VM changes for monitoring (more statistical data),
> some VM changes around the memory growth versus GC activity decision.
>
> The logic to tweak things lurks in the image, not the VM.
>
> Let's see where my message went. Otherwise the changesets are on my 
> idisk.
>
>
> On Jan 18, 2005, at 6:28 PM, Andreas Raab wrote:
>
>>>> Tim - is there any chance that we can get these changes into the 3.8
>>>> VMMaker? This stuff will be critical for the next Tweak version and 
>>>> having
>>>> it in the official 3.8 would heavily simplify migration.
>>> Perhaps you could chat with John about the GC monitoring code he
>>> suggested recently. There is a degree of overlap that you might be  able
>>> to mutually remove, making my lif emuch simpler.
>>
>> I haven't seen that code ... but what I am proposing here should allow 
>> us to run tuning code from the image instead of the VM.
>>
>>> Aaaannnnnd, how is this going to relate to the 64bit code? I'm still
>>> waiting for some answers about that before doing anything much to
>>> vmmaker.
>>
>> Just asked Ian about this today (I'll defer to him for an ultimate 
>> answer).
>>
>> Cheers,
>>  - Andreas
>>
>>
>>
>> -------------------------------------------------------
>> The SF.Net email is sponsored by: Beat the post-holiday blues
>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>> _______________________________________________
>> Squeak-VMdev mailing list
>> Squ...@li...
>> https://lists.sourceforge.net/lists/listinfo/squeak-vmdev
>>
>>
> --
> ======================================================================== 
> ===
> John M. McIntosh <jo...@sm...> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ======================================================================== 
> ===
>