[squeak-dev] Re: How weak finalization affects the performance
siguctua at gmail.com
Thu Nov 4 21:27:05 UTC 2010
On 4 November 2010 22:32, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi Igor,
> I already explained the ratchet technique we use in VisualWorks which
> involves no delay and simply takes advantage of the fact that Smalltalk
> processes are cooperatively scheduled within priorities. This both avoids
> creating a process per finalized object and avoids the finalization process
> stalling if there is an error in a finalizer. What's not to like?
I remember your explanation quite well, and i think this is a way to go.
By saying that VM just signals a semaphore and "I don't see what can
be improved here.",
i meant that there is no need to complicate things further at VM side.
At image side, however there is a space for improvement. And i plan to
address that, give it a time :)
> On Thu, Nov 4, 2010 at 1:24 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>> On 4 November 2010 21:58, Chris Muller <asqueaker at gmail.com> wrote:
>> >>> Here, at each GC cycle, a 'dict finalizeValues' will be sent,
>> >>> which leads to looping over 1000 entries.
>> >>> Add dict with 10000 entries, and you will loop over 10000 after each
>> >>> GC.
>> >> You should never register WeakKeyDictionaries to the finalization
>> >> process.
>> >> They are not thread safe.
>> >> Since the next VMs will support your new finalization scheme, I see no
>> >> benefit from the delay.
>> > Igor, I know I'm very late to this discussion but.. The other benefit
>> > to the Delay that your finalization scheme does not solve is the fact
>> > that there could be a lot of _registrants_ in WeakArray that need to
>> > be enumerated after every GC.
>> > Correct me if I'm wrong, but your finalization fix only allows each
>> > individual registrant to "clean quickly" rather than do a full
>> > enumeration; is that right?
>> > If there are 5000 registrants in WeakArray, the delay would prevent
>> > enumerating 5000 elements after every GC unless 5 seconds have
>> > elapsed. So we are we not best off with _both_ your finalization fix
>> > _and_ the delay...?
>> Yes. Usually, a weak array populated by weakregistry instances.
>> And usually there are few of them.
>> Of course it may pose a problem, if you put it on stress, like adding
>> 5000 registrants.
>> And of course, new finalization does not addressing this problem.
>> Because weak dependents
>> work for different purpose: be notified upon each GC cycle.
>> And particular registrant can do anything during hanling a
>> notification. And it can be something completely unrelated to weak
>> VM just signals a semaphore, when GC done. The rest is up to image
>> what to do. I don't see what can be improved here.
>> > - Chris
>> Best regards,
>> Igor Stasenko AKA sig.
Igor Stasenko AKA sig.
More information about the Squeak-dev