Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)
Hi igor do you understand why the previous definition was cachedDefinitions Definitions ifNil: [Definitions := WeakIdentityKeyDictionary new. WeakArray addWeakDependent: Definitions]. ^ Definitions Stef On Oct 1, 2010, at 7:34 PM, Igor Stasenko wrote:
Here the simple fix for it.
-- Best regards, Igor Stasenko AKA sig. <mc-cache-fix.1.cs>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 2 October 2010 19:47, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi igor
do you understand why the previous definition was
cachedDefinitions     Definitions ifNil: [Definitions := WeakIdentityKeyDictionary new.  WeakArray addWeakDependent: Definitions].     ^ Definitions
i don't. :) It just a way to free memory as fast as possible. But its really not worth spending so much CPU in order to save few bytes of memory.
Stef
On Oct 1, 2010, at 7:34 PM, Igor Stasenko wrote:
Here the simple fix for it.
-- Best regards, Igor Stasenko AKA sig. <mc-cache-fix.1.cs>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On 02.10.2010 19:01, Igor Stasenko wrote:
On 2 October 2010 19:47, Stéphane Ducasse<stephane.ducasse@inria.fr> wrote:
Hi igor
do you understand why the previous definition was
cachedDefinitions Definitions ifNil: [Definitions := WeakIdentityKeyDictionary new. WeakArray addWeakDependent: Definitions]. ^ Definitions
i don't. :)
It just a way to free memory as fast as possible. But its really not worth spending so much CPU in order to save few bytes of memory. Without registering the dict for finalization, the values won't ever be removed with the current implementation. Which can be somewhat hampering to performance once you have lots of nil-keyed elements all stashed from index 1 and onwards after a rehash.
Cheers, Henry
On 3 October 2010 03:13, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
 On 02.10.2010 19:01, Igor Stasenko wrote:
On 2 October 2010 19:47, Stéphane Ducasse<stephane.ducasse@inria.fr>  wrote:
Hi igor
do you understand why the previous definition was
cachedDefinitions     Definitions ifNil: [Definitions := WeakIdentityKeyDictionary new.  WeakArray addWeakDependent: Definitions].     ^ Definitions
i don't. :)
It just a way to free memory as fast as possible. But its really not worth spending so much CPU in order to save few bytes of memory.
Without registering the dict for finalization, the values won't ever be removed with the current implementation.
They are removed. After each package load/unload operation. I don't see a reason to do this more often.
Which can be somewhat hampering to performance once you have lots of nil-keyed elements all stashed from index 1 and onwards after a rehash.
In Pharo, weak dict knows how to reuse expired associations: at: key put: anObject "Set the value at key to be anObject. If key is not found, create a new entry for key and set is value to anObject. Answer anObject." | index element | key isNil ifTrue:[^anObject]. index := self scanForEmpty: key. "There should always be room." index = 0 ifTrue: [ self error: 'No space left in dictionary' ]. element := array at: index. element == nil ifTrue: [self atNewIndex: index put: (WeakKeyAssociation key: key value: anObject)] ifFalse: [ element expired ifTrue: [ tally := tally + 1]. element key: key. element value: anObject. self fullCheck. ]. ^ anObject
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On 03.10.2010 05:47, Igor Stasenko wrote:
On 3 October 2010 03:13, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
On 02.10.2010 19:01, Igor Stasenko wrote:
On 2 October 2010 19:47, Stéphane Ducasse<stephane.ducasse@inria.fr> wrote:
Hi igor
do you understand why the previous definition was
cachedDefinitions Definitions ifNil: [Definitions := WeakIdentityKeyDictionary new. WeakArray addWeakDependent: Definitions]. ^ Definitions
i don't. :)
It just a way to free memory as fast as possible. But its really not worth spending so much CPU in order to save few bytes of memory. Without registering the dict for finalization, the values won't ever be removed with the current implementation. They are removed. After each package load/unload operation. I don't see a reason to do this more often. If they are removed explicitly, then yes. But then again, if that's the case, why use a weak dictionary in the first place? Which can be somewhat hampering to performance once you have lots of nil-keyed elements all stashed from index 1 and onwards after a rehash.
In Pharo, weak dict knows how to reuse expired associations:
And when do they expire? Only when they are either finalized, or removed explicitly. So if you do neither, they will stay indefinately without being removed/reused. Cheers, Henry
On 3 October 2010 12:36, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
 On 03.10.2010 05:47, Igor Stasenko wrote:
On 3 October 2010 03:13, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> Â wrote:
 On 02.10.2010 19:01, Igor Stasenko wrote:
On 2 October 2010 19:47, Stéphane Ducasse<stephane.ducasse@inria.fr>  wrote:
Hi igor
do you understand why the previous definition was
cachedDefinitions     Definitions ifNil: [Definitions := WeakIdentityKeyDictionary new.  WeakArray addWeakDependent: Definitions].     ^ Definitions
i don't. :)
It just a way to free memory as fast as possible. But its really not worth spending so much CPU in order to save few bytes of memory.
Without registering the dict for finalization, the values won't ever be removed with the current implementation.
They are removed. After each package load/unload operation. I don't see a reason to do this more often.
If they are removed explicitly, then yes. But then again, if that's the case, why use a weak dictionary in the first place?
i don't know much about MC to tell for sure.
Which can be somewhat hampering to performance once you have lots of nil-keyed elements all stashed from index 1 and onwards after a rehash.
In Pharo, weak dict knows how to reuse expired associations:
And when do they expire? Only when they are either finalized, or removed explicitly. So if you do neither, they will stay indefinately without being removed/reused.
no. they expiring when key become nil.
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On 03.10.2010 11:59, Igor Stasenko wrote:
On 3 October 2010 12:36, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
On 03.10.2010 05:47, Igor Stasenko wrote:
On 3 October 2010 03:13, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
On 02.10.2010 19:01, Igor Stasenko wrote:
On 2 October 2010 19:47, Stéphane Ducasse<stephane.ducasse@inria.fr> wrote:
Hi igor
do you understand why the previous definition was
cachedDefinitions Definitions ifNil: [Definitions := WeakIdentityKeyDictionary new. WeakArray addWeakDependent: Definitions]. ^ Definitions
i don't. :)
It just a way to free memory as fast as possible. But its really not worth spending so much CPU in order to save few bytes of memory. Without registering the dict for finalization, the values won't ever be removed with the current implementation. They are removed. After each package load/unload operation. I don't see a reason to do this more often. If they are removed explicitly, then yes. But then again, if that's the case, why use a weak dictionary in the first place? i don't know much about MC to tell for sure.
Which can be somewhat hampering to performance once you have lots of nil-keyed elements all stashed from index 1 and onwards after a rehash.
In Pharo, weak dict knows how to reuse expired associations:
And when do they expire? Only when they are either finalized, or removed explicitly. So if you do neither, they will stay indefinately without being removed/reused. no. they expiring when key become nil.
You'd think so, yes. However, see implementor of WeakKeyAssociation>>#expired, and senders of #expire. Cheers, Henry
On 3 October 2010 13:03, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
 On 03.10.2010 11:59, Igor Stasenko wrote:
On 3 October 2010 12:36, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> Â wrote:
 On 03.10.2010 05:47, Igor Stasenko wrote:
On 3 October 2010 03:13, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> Â Â wrote:
 On 02.10.2010 19:01, Igor Stasenko wrote:
On 2 October 2010 19:47, Stéphane Ducasse<stephane.ducasse@inria.fr>  wrote:
Hi igor
do you understand why the previous definition was
cachedDefinitions     Definitions ifNil: [Definitions := WeakIdentityKeyDictionary new.  WeakArray addWeakDependent: Definitions].     ^ Definitions
i don't. :)
It just a way to free memory as fast as possible. But its really not worth spending so much CPU in order to save few bytes of memory.
Without registering the dict for finalization, the values won't ever be removed with the current implementation.
They are removed. After each package load/unload operation. I don't see a reason to do this more often.
If they are removed explicitly, then yes. But then again, if that's the case, why use a weak dictionary in the first place?
i don't know much about MC to tell for sure.
Which can be somewhat hampering to performance once you have lots of nil-keyed elements all stashed from index 1 and onwards after a rehash.
In Pharo, weak dict knows how to reuse expired associations:
And when do they expire? Only when they are either finalized, or removed explicitly. So if you do neither, they will stay indefinately without being removed/reused.
no. they expiring when key become nil.
You'd think so, yes. However, see implementor of WeakKeyAssociation>>#expired, and senders of #expire.
Oh, you are right. They are not reused unless marked as expired (associatin's value == association). But concerning speed, then my benchmark should show an opposite results. :) cache holding a pairs of: compiledmethod -> MCMethodDefinitions. Compiled methods usually gone when you either recompiling class or removing it from system. This is why i put #finalizeValues after package loading/unloading. But if you think it worth adding it into some other places, then tell me where. Still, putting it into FinalizationDependents is bad idea.
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
And this is why I had that #isTimeToClean (90-second timer) hack in the MaDictionary's... On Sat, Oct 2, 2010 at 12:01 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 2 October 2010 19:47, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi igor
do you understand why the previous definition was
cachedDefinitions     Definitions ifNil: [Definitions := WeakIdentityKeyDictionary new.  WeakArray addWeakDependent: Definitions].     ^ Definitions
i don't. :)
It just a way to free memory as fast as possible. But its really not worth spending so much CPU in order to save few bytes of memory.
Stef
On Oct 1, 2010, at 7:34 PM, Igor Stasenko wrote:
Here the simple fix for it.
-- Best regards, Igor Stasenko AKA sig. <mc-cache-fix.1.cs>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Chris Muller -
Henrik Sperre Johansen -
Igor Stasenko -
Stéphane Ducasse