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

Levente Uzonyi leves at elte.hu
Tue Mar 9 00:08:44 UTC 2010


On Tue, 9 Mar 2010, Igor Stasenko wrote:

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

I don't see any use of it, but someone else may. We allow everyone to 
evaluate Object superclass: Object, even though we know that it will crash 
the system.


Levente

>
>>
>> Levente
>>
>
> -- 
> Best regards,
> Igor Stasenko AKA sig.
>


More information about the Vm-dev mailing list