[Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)
I uploaded new changesets to http://code.google.com/p/pharo/issues/detail?id=3002 I tested applying them in Pharo-Core-#12159 and then updating an image after that. After update: MCMethodDefinition cachedDefinitions size is 18668 But image don't feels slow. As a side note, i recommend to review the MC caching mechanism towards avoiding putting so much load on finalization process (such as scanning 18k entries to find dead objects). This is actually the purpose of new finalization scheme: - it allows to avoid scanning whole weak dictionary in order to get rid of expired associations. I'm already implemented a variant of self-cleaning weak dictionary for Magma, which using new finalization scheme, and avoids scanning huge number of entries to discover few of them, which became garbage. -- Best regards, Igor Stasenko AKA sig.
On Fri, 1 Oct 2010, Igor Stasenko wrote:
I uploaded new changesets to http://code.google.com/p/pharo/issues/detail?id=3002
I tested applying them in Pharo-Core-#12159 and then updating an image after that.
After update: MCMethodDefinition cachedDefinitions size is 18668
But image don't feels slow.
As a side note, i recommend to review the MC caching mechanism towards avoiding putting so much load on finalization process (such as scanning 18k entries to find dead objects).
This is actually the purpose of new finalization scheme: - it allows to avoid scanning whole weak dictionary in order to get rid of expired associations.
WeakKeyDictionaries shouldn't be added to the finalization process at all. In the current case there's no finalization action at all, so it's totally pointless IMO. And these dictionaries are not thread-safe, so bad things can happen if they are registered with the finalization process.
I'm already implemented a variant of self-cleaning weak dictionary for Magma, which using new finalization scheme, and avoids scanning huge number of entries to discover few of them, which became garbage.
Squeak's WeakKeyDictionaries are self cleaning, though the there's no guarantee that finalization action is performed when the key is GC'd. Levente
-- 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
On 1 October 2010 20:05, Levente Uzonyi <leves@elte.hu> wrote:
On Fri, 1 Oct 2010, Igor Stasenko wrote:
I uploaded new changesets to http://code.google.com/p/pharo/issues/detail?id=3002
I tested applying them in Pharo-Core-#12159 and then updating an image after that.
After update: MCMethodDefinition cachedDefinitions size is 18668
But image don't feels slow.
As a side note, i recommend to review the MC caching mechanism towards avoiding putting so much load on finalization process (such as scanning 18k entries to find dead objects).
This is actually the purpose of new finalization scheme: - it allows to avoid scanning whole weak dictionary in order to get rid of expired associations.
WeakKeyDictionaries shouldn't be added to the finalization process at all. In the current case there's no finalization action at all, so it's totally pointless IMO. And these dictionaries are not thread-safe, so bad things can happen if they are registered with the finalization process.
well..then we probably should fix this: MCMethodDefinition>>cachedDefinitions Definitions ifNil: [Definitions := WeakIdentityKeyDictionary new. WeakArray addWeakDependent: Definitions]. ^ Definitions
I'm already implemented a variant of self-cleaning weak dictionary for Magma, which using new finalization scheme, and avoids scanning huge number of entries to discover few of them, which became garbage.
Squeak's WeakKeyDictionaries are self cleaning, though the there's no guarantee that finalization action is performed when the key is GC'd.
it depends how badly you need to keep things clean as soon as its possible :) It is really not necessary to add cachedDefinitions to weakdependets and check them each time after GC. In case of MC, i think a dead-keys cleanup should be triggered only after package loading/unloading, but not during each GC.
Levente
-- 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
_______________________________________________ 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.
I just tried to update image with old cache: [ Utilities updateFromServer] timeToRun 397707 and without it: [ Utilities updateFromServer] timeToRun 347708 397707 / 347708 asFloat 1.143795943722894 so, roughly 14% of CPU time (about 50 seconds) wasted on scanning the cache at each GC. Of course this measure a bit dirty, because there a network activity involved . On 1 October 2010 20:33, Igor Stasenko <siguctua@gmail.com> wrote:
Here the simple fix for it.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
participants (2)
-
Igor Stasenko -
Levente Uzonyi