John M McIntosh wrote:

> Ooo finalization, my favourite nasty problem, in past experience on 
> other Smalltalks watching production systems
> burn, is that finalization is a process that happens in the future at 
> the wrong time and at the wrong rate. Usually
> this is discovered after the system goes into production.
>
> That said Andreas comment about doing finalization over a time period 
> is  a good idea, keep in mind that you might
> need to apply some adaptive feedback say to ensure the finalization 
> work doesn't cause performance concerns,  by
> varying how many you look at in a pass based on the array size or 
> something.  It's possible finalization could take 20 seonds
> if things are busy, however such logic was the downfall of earlier 
> versions of VisualWorks which would finalizes only one
> object per new space GC collection.

This sounds like another useful improvement.  What do you think of the
compaction code I posted?  Seem like a waste of time?  I'm working on a
version which gives some feedback.  I've got a pre-production project
which will be a good testbed for this stuff.  The number of active users
is small but their sessions should last all day.

Another (naive, sorry) question: With the "delayed" version there may be
several pending finalization signals but we only need to run through the
loop once.  What we need are:

conditionVariable ifSetClearAndDo: [some block]

Given that the VM's GC can't block on the "condition variable", though,
it's use here wouldn't really work.  But we can do a poor-man's job of it:

FinalizationSemaphore wait.
pending := FinalizationSemaphore excessSignals.  "you'd have to add that
accessor"
[pending > 0] whileTrue: [FinalizationSemaphore wait. pending := pending
- 1]

This counts on absolutely noone else "waiting" on the finalization
semaphore.  I think that's reasonable given it is a class var in
WeakArray.  Comments?  Leave out the part about a semaphore's signal
count being private and I'm a bad boy for even thinking about this :-)

>
>
> lastly don't forget
>
>     Smalltalk setGCBiasToGrowGCLimit: 16*1024*1024.
>     Smalltalk setGCBiasToGrow: 1.

Unfortunately I'm working in 3.7 exclusively and this seems to be
missing.  I've bookmarked this e-mail for when I move to a newer
VM/image. :-) 

David