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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Igor Stasenko
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@41 . 4114@0}

While its not much better at first benchmark (since using the same
approach to store objects in one dictionary),
while other is significant, since there is no longer need to scan a
whole collection to detect an items which become a garbage.

Btw, i wonder, why current WeakRegistry using a WeakKeyDictionary
instead of WeakIdentityKeyDictionary?
Isn't a weak refs is identity-based?

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.

--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

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

Levente Uzonyi-2
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@41 . 4114@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.

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


Levente

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