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 :)


> 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.
>>
>
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.