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

Levente Uzonyi leves at elte.hu
Mon Mar 8 23:12:40 UTC 2010


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.

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


Levente

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


More information about the Vm-dev mailing list