Re: [Squeak-VMdev] Re: GC improvements

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

Hi John,

> I have no problem changing this to use a external semaphore index.
> The check then I'd guess would check to check for a non-zero value in 
> that global.

I prefer this solution.

>> * The logic in incrementalGC for growing namely:
>
> This code is where the problem with:
>> What I found was an issue which we hadn't realized is there, well I'm 
>> sure people have seen it, but don't know why...
>> What happens is that as we are tenuring objects we are decreasing the 
>> young space from 4MB to Zero.

Ah, I see. Yes that'd be really bad.

>> Note how we allocate 76 objects, do a young space GC, then have two 
>> survivors, finally we reach the 200K minimum GC
>> threshold and do a full GC followed by growing young space. However  this 
>> process is very painful.
>
> By saying we want some slack growHeadroom*3/2 - (self sizeOfFree: 
> freeBlock) we avoid the above problem.

I see. Yes this makes sense. (btw, I'm not sure if these parameter choices 
are best but I guess since they aren't worse than what's there they must be 
good enough ;-)

> In the smalltalk code is a post check to say if we've grown N MB  between 
> full GCs then it's time to do another one, this prevents  uncontrolled 
> growth.
> I could add that check in the VM? Should we? If the GC tuning process 
> stops running then the VM will grow to the maximum Virtual memory size.
> I did not add it to the VM code since I wanted to minimize the code 
> there.

With this aggressive growth strategy I think we should have a (VM) parameter 
which controls when to run a full GC depending on how much we've grown. 
Having a GC tuner sit there all the time and watch things fly by doesn't 
look like the best solution to me.

On the other hand it seems like in this case we probably should be following 
the same strategy in sufficientSpaceAfterGC:, shouldn't we? Here, we just GC 
and then grow and it seems that if we're okay with aggressive growths me 
grow here, too.

>> * 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.
>
> Well I wanted to collect data, I wonder tho if adding these new 
> instructions  it makes any measurable difference, maybe integer unit 47 
> on that cpu now gets used? Somehow I'd rather leave them, unless you  can 
> show they are issues?

Well, the major reason why I don't like the insns there is that it is so 
hard to measure the difference (otherwise I would have just done it). If you 
know how to get accurate measures here (say to be able to spot a speed 
difference of  1% reliably) let me know.

> Remember we don't have anyway to collect that type of data right now.

If you look at them, all can be computed by other means, say:

statMarkCount:
    Number of marked objects ==
        Number of roots + Number of survivors

statSweepCount
    Number of objects in young space before GC ==
        Number of survivors of last GC + allocationsBetweenGC

statMkFwdCount
    Number of objects for which fwdBlocks were created ==
        Number of survivors

statCompMoveCount
    Number of chunks touched in incr. compaction ==
        statSweepCount

So there really isn't any need to count them one by one (if the result of 
counting would be different from the above formulaes it's time to get a new 
CPU which gets addition right ;-)

Cheers,
  - Andreas