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

[Levente Uzonyi]

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:
>>
>>>
>>> 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.
>>
>
> Well, if someone cares, then he actually can make own registry class,
> which allows copying. But why we should care, by leaving a potential
> security hole open?
> I don't think that this is normal to rely on good manners of users and
> expect them to not attempt to do something wrong. In contrast, a
> protocols and interfaces should discourage user from abuse. At least,
> an author could state where it is safe to use and where is not.
> A copy protocol for weak registry is far from being safe.
> In that situation is better to generate an error, indicating that such
> use is not foreseen by author, rather than trying to implement
> something which 'possibly could work' :)

I still don't see how is it unsafe.


Levente

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