William Harford wrote:

>
> On Mar 24, 2006, at 9:50 PM, Andreas Raab wrote:
>
>>
>> True. From what I've seen over at the Seaside mailing list it seems 
>> pretty clear that the main issue is that the finalization process 
>> simply kicks in *way* to often. Have you guys (since you're having 
>> the problem I think it's appropriate if you can experiment with it  a
>> little ;-) thought about tweaking the finalization process to run  at
>> most (say) 20/sec? This is a simple change (see attached CS)  which
>> could have dramatic impact on your performance. The obvious 
>> disadvantage, of course, is that this renders any assumptions about 
>> "Smalltalk garbageCollect" having an immediate effect meaningless 
>> (which is the main reason the finalization process is implemented 
>> the way it is).
>
>
> I made some changes like this soon after I posted a message on the 
> Seaside mailing list.
>
> I also started running the Finalization process at a lower priority 
> level systemBackgroundPriority. I was not sure if this would cause 
> any problems (is there some sort of race condition I should be 
> worried about) but the changes have evened out my problems. It has 
> only been a couple days but it appears that it may have helped 
> mitigate some of the WeakArray finalization problems.
>
> Thanks
> Will
>
>
>
Out of curiosity how large is your WeakArray class var
FinalizationDependents?  When I had problems this array had grown to
~100k BTW.  On my server image (which has been stable for a long time
now) the array is 1k.


My understanding of the notification mechanism is that each weak object
collection signals the semaphore once so if you get a bunch of
collections you are iterating over this array quite a few times.  So,
even with the delay you're going to run through the loop over the weak
dependents once for each collected weak object ref.  That's a lot of
wasted cycles since after the first pass you probably
#finalizaedValue-ed everyone that needed it.  Growth only occurs in
addWeakDependent: when there are no empty slots so I'm surprised that it
ever got this large.  Anyway after a short time it is quite sparsely
populated so it wouldn't be hard to shrink it down.  One could
instrument #finalizationProcess to count the nil entries and when they
cross a low water mark you could compact the array.  Continuing along my
"amateur's can do it too" theme I went ahead and coded this...I'm not
convinced that it is the right thing to do but it seems worth a try.

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: FinalizationDependentsCompact.3.cs
Type: text/x-csharp
Size: 1309 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20060325/ddfdc5ce/FinalizationDependentsCompact.3.bin