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?

cheers
Eliot

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
> stuff.
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20101104/20158991/attachment.htm