Re: [Squeak-VMdev] Re: GC improvements

[John M M. <jo...@ma...>]

(Sent to list too)

Ok, I consolidated all of this, added a prim to turn the biasGrowth  
behavior on where the grow and post fullGC logic is in the interp.c  
code, versus being partially in the image. Also a prim to set the  
threshold for doing the fullGC if we have grown by N bytes. Thus you  
can turn off/on and set the boundary. Left in the other prims as  
agreed.

However when I when to cross check performance and impact I immediately  
ran into a performance problem which took some time to figure out.

If you take the freecell game and select game 1 (the benchmark) then  
instead of completing in about 4 seconds, it took 85 seconds. Ick.   
Well it's going to be a long night, now which of my GC changes,  
Andreas' changes or Ian's weak object changes, or my changes to  
drawing/flushing/locking causes this.  Many hours later...

So what is happening, also someone could confirm these details.

a) The 10 entries I have for FinalizationDependents have sizes of #(0 2  
0 3 2 55825 nil nil nil nil). You will note the one with 55,825  
entries. This actually a 98K or so WeakIdenityKeyDictionary of  
CompiledMethods.

b) On every animated card move this code in markAndTrace:  is triggered  
to increment weakRootCount
	(self isWeakNonInt: oop) ifTrue: [
		"Set lastFieldOffset before the weak fields in the receiver"
		lastFieldOffset := (self nonWeakFieldsOf: oop) << 2.
		"And remember as weak root"
		weakRootCount := weakRootCount + 1.
		weakRoots at: weakRootCount put: oop.
	] ifFalse: [
		"Do it the usual way"
		lastFieldOffset _ self lastPointerOf: oop.
	].

which later triggers
	1 to: weakRootCount do:[:i| self finalizeReference: (weakRoots at: i)].

which leds to signaling the FinalizationSemaphore which wakes up the  
FinalizationProcess which
calls
finalizeValues on each WeakArray instance (and subclass instance)
That has some issues.
One is that it iterates over the 98K WeakIdenityKeyDictionary and then  
cheerfully does a rehash even if it didn't do anything.
First should  we only do the rehash if we actually tamper with the  
data?  Aka this suggestion.

finalizeValues
	"remove all nil keys and rehash the receiver afterwards"
	| assoc hit |
	hit _ false.
	1 to: array size do:[:i|
		assoc _ array at: i.
		(assoc notNil and:[assoc key == nil]) ifTrue:[array at: i put: nil.  
hit _ true].
	].
	hit ifTrue: [self rehash].

Well adding that makes it a bit faster, still hunting thru 98K elements  
every card animation move isn't fun.

PS Isn't it a bit ugly to iterate over all the elements of Weak things  
looking for null entries, versus passing up a cluestick?
I'll note VisualAge had issues years ago, they would pass up the OOps,  
one at a time, finalization on large numbers took *forever*.
Then they moved to passing up N elements, where when N overflowed you  
were toast. Can't recall what it is now, but they
got past losing entries.



On Jan 20, 2005, at 11:07 AM, John M McIntosh wrote:

> On Jan 19, 2005, at 9:32 PM, Andreas Raab wrote:
>
>>> What I could do is integrate your changes with mine over the  
>>> weekend,  and unless you want to take on that task?
>>
>> If you can find the time this would be great (I may or may not get  
>> around to it).
>> To summarize:
>> * Use gcSemaIndex instead of TheGCSemaphore for compatibility
>> * Trigger growth logic in tenuring upon presence of gc sema
>> * Remove the stats from the inner loops of the GC logic.
>> Is this it?
>>
>> Cheers,
>>  - Andreas
>
> Ok, but I'll make one change. I'll see about a flag to turn the new  
> behavior on versus re-using the
> semaphore. That way you don't mix both desires, one of getting IGC/GC  
> notification, the other of triggering the new behavior.
>
> ======================================================================= 
> ====
> John M. McIntosh <jo...@sm...> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ======================================================================= 
> ====

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