Hi Igor,<div><br></div><div> 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?</div>
<div><br></div><div>cheers</div><div>Eliot<br><br><div class="gmail_quote">On Thu, Nov 4, 2010 at 1:24 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5">On 4 November 2010 21:58, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
>>> Here, at each GC cycle, a 'dict finalizeValues' will be sent,<br>
>>> which leads to looping over 1000 entries.<br>
>>> Add dict with 10000 entries, and you will loop over 10000 after each GC.<br>
>><br>
>> You should never register WeakKeyDictionaries to the finalization process.<br>
>> They are not thread safe.<br>
>><br>
>> Since the next VMs will support your new finalization scheme, I see no<br>
>> benefit from the delay.<br>
><br>
> Igor, I know I'm very late to this discussion but.. The other benefit<br>
> to the Delay that your finalization scheme does not solve is the fact<br>
> that there could be a lot of _registrants_ in WeakArray that need to<br>
> be enumerated after every GC.<br>
><br>
> Correct me if I'm wrong, but your finalization fix only allows each<br>
> individual registrant to "clean quickly" rather than do a full<br>
> enumeration; is that right?<br>
><br>
> If there are 5000 registrants in WeakArray, the delay would prevent<br>
> enumerating 5000 elements after every GC unless 5 seconds have<br>
> elapsed. So we are we not best off with _both_ your finalization fix<br>
> _and_ the delay...?<br>
><br>
<br>
</div></div>Yes. Usually, a weak array populated by weakregistry instances.<br>
And usually there are few of them.<br>
Of course it may pose a problem, if you put it on stress, like adding<br>
5000 registrants.<br>
And of course, new finalization does not addressing this problem.<br>
Because weak dependents<br>
work for different purpose: be notified upon each GC cycle.<br>
And particular registrant can do anything during hanling a<br>
notification. And it can be something completely unrelated to weak<br>
stuff.<br>
<br>
VM just signals a semaphore, when GC done. The rest is up to image<br>
what to do. I don't see what can be improved here.<br>
<br>
> - Chris<br>
<div><div></div><div class="h5">><br>
><br>
<br>
<br>
<br>
--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
<br>
</div></div></blockquote></div><br></div>