[Vm-dev] [ENH] A better finalization support (VM & language side)

[Igor Stasenko]

2010/3/9 Levente Uzonyi <leves at elte.hu>:
>
> On Tue, 9 Mar 2010, Igor Stasenko wrote:
>
>>
>> On 9 March 2010 00:44, Levente Uzonyi <leves at elte.hu> wrote:
>>>
>>> On Mon, 8 Mar 2010, Igor Stasenko wrote:
>>>
>>>>
>>>> Please, review the
>>>> http://bugs.squeak.org/view.php?id=7473
>>>>
>>>> There are two sets of changesets - one for vmmaker and other is for
>>>> language-side.
>>>>
>>>> A VMMaker changeset is based on VMMaker-dtl.159.
>>>>
>>>> Here the little benchmark, between old and new weak registries:
>>>>
>>>> { WeakRegistry. WeakFinalizationRegistry } collect: [:class |
>>>>  | registry weaklings time1 time2 |
>>>>  registry := class new.
>>>>  WeakArray removeWeakDependent: registry.
>>>>
>>>>  weaklings := (1 to: 100000) collect: [:i | Object new ].
>>>>  time1 := [ weaklings do: [:each | registry add: each ] ] timeToRun.
>>>>  weaklings at: 100 put: nil.
>>>>  Smalltalk garbageCollect; garbageCollect.
>>>>  time2 := [ registry finalizeValues ] timeToRun.
>>>>  time1 @ time2
>>>> ]
>>>> {7816 at 41 . 4114 at 0}
>>>>
>>>> While its not much better at first benchmark (since using the same
>>>> approach to store objects in one dictionary),
>>>
>>> I took a quick look and found that you omitted the semaphore from
>>> WeakFinalizationRegistry. I think it won't work this way.
>>>
>>
>> The point is, that new implementation don't touching the
>> 'valueDictionary' during finalization,
>> and therefore from this side, there is no concurrency issues.
>>
>> Adding/accessing items in the list is not protected. But i think the
>> main reason why we having a semaphore here is to protect from
>> interrupts caused by garbage collector and finalization process.
>> If you think we should also protect it from concurrent access , when
>> populating it - i could add the semaphores.
>
> I think it's a must. For example you can always open two sockets or two files concurrently. Or close one while opening another, etc.
>
No problem, it could be added quite easily.

>>
>>>> while other is significant, since there is no longer need to scan a
>>>> whole collection to detect an items which become a garbage.
>>>
>>> That's great.
>>>
>>>>
>>>> Btw, i wonder, why current WeakRegistry using a WeakKeyDictionary
>>>> instead of WeakIdentityKeyDictionary?
>>>> Isn't a weak refs is identity-based?
>>>>
>>>
>>> I found it strange too, but I think the users of WeakRegistry don't
>>> implement their own #hash and #=, though I didn't check that. Using a
>>> WeakIdentityKeyDictionary could also mean better performance in most cases.
>>>
>>>> I am also a bit wonder, why WeakRegistry has to support a copy protocol?
>>>> It may lead to unpredictable behavior once you try to copy such kind
>>>> of container, no matter how well you protect it.
>>>
>>> I think copy is supported because WeakRegistry is a collection. I wonder how
>>> could you get the unpredictable behavior with the current implementation.
>>>
>>
>> well, potentially, it could lead to making finalization twice (by each
>> registry object), since when you copying registry you doubling the
>> number of references to all executor objects which is held strongly by
>> registry.
>
> I think it's the responsibility of the user of #copy to avoid that. And the user doesn't have to do much, because the copy is not registered in WeakArray for finalization, so sending #copy to WeakRegistry won't cause any harm IMHO.
>

why allowing user to go into absurdly direction? Why just
#shouldNotImplement it?
Do you see any good and practical uses of weakregistry copies?

>
> Levente
>

-- 
Best regards,
Igor Stasenko AKA sig.