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

Igor Stasenko siguctua at gmail.com
Tue Mar 9 03:33:00 UTC 2010

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

A simple copy is fine. A copy, which then registered in weak
dependents creating a problem.

I even think that weak registry should not behave as collection at all,
and having only #add: method, with no ability to remove items.

The only use of #remove: i see is in Socket and StandardFileStream,
which implement #unregister: in own class side.

Now , if you look at my implementation, you could see that there is a
way to completely avoid the need in removing items from a
valueDictionary which is pairs of  <weakref> -> <executor>.

A solution:
- add a 'finalizer' ivar to Socket/StandardFileStream
- by registering a socket in registry, retrieve an instance of
WeakFinalizerItem as a result of registration and store it into
'finalizer' ivar.

- on #destroy, simply nil-out all of the finalizer's ivars, so there
is no chances that once socket become garbage, it will trigger an
executor's #finalize method, which were registered previously in

- forget about removing the finalizer manually from registry, because
an instance of WeakFinalizerItem which is held by 'valueDictionary' in
registry will eventually be reclaimed, once dictionary will discover
that corresponding key is nil.

What you think?

> Levente

Best regards,
Igor Stasenko AKA sig.

More information about the Vm-dev mailing list