[squeak-dev] Re: How weak finalization affects the performance
siguctua at gmail.com
Thu Nov 4 20:24:37 UTC 2010
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
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
Igor Stasenko AKA sig.
More information about the Squeak-dev