>
>[Re: GC]
>>  The penalties of having a large methodcache are that there is more to
>>  flush on GC's... Which reminds me, why is 'allocations
>>  between gc's' still set at 4000?
>
>It works. And nicely at that even on small machine. Heck, it even worked
>nicely on my 486DX2/66 (if anyone remembers what this is ;-) which I used
>for porting Squeak.
>
>>  Anyone up for changing the default to 40000?  (still under 10ms)
>
>Hm ... not really. At least not as long you can't show a serious performance
>improvement. Which I find hard to believe, mostly because John Mc recently
>changed the IGC mcache flush to be selective (e.g., flush only entries that
>are actually in GC range). So except from enumerating the cache there's not
a lot going on wrt GC.

Hi, actually I'm making some changes in this area to float the 
allocation number based on factors like how much free space is there 
and how long does it take to do the last GC. So if young space GC 
takes under N milliseconds then we would increment the number a bit. 
If it goes over N then we decrement. That way the number can float up 
or down depending on conditions.

The other thing to look at is how tenuring is done, right now it's 
all of young space when we reach a trigger point, but maybe it should 
be part of young space, or after a few generations that are too big. 
And last but not least some intelligence to solve the excessive 
remember table scanning issue.



-- 
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================