2010/10/19 Levente Uzonyi <[email protected]>: > On Tue, 19 Oct 2010, Igor Stasenko wrote: > >> On 19 October 2010 00:30, Henrik Sperre Johansen > > <[email protected]> wrote: >> >> On 18.10.2010 23:21, Igor Stasenko wrote: >>> >>> 2010/10/19 Levente Uzonyi<[email protected]>: >>>> >>>> On Mon, 18 Oct 2010, Nicolas Cellier wrote: >>>> >>>>> 2010/10/18 Igor Stasenko<[email protected]>: >>>>>> >>>>>> On 18 October 2010 23:18, Nicolas Cellier >>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> 2010/10/17 Levente Uzonyi<[email protected]>: >>>>>>>> >>>>>>>> On Sat, 16 Oct 2010, Bart Veenstra wrote: >>>>>>>> >>>>>>>>> Hi list, >>>>>>>>> >>>>>>>>> I have been working with Pharo for almost a month now, and I >>>>>>>>> suspect >>>>>>>>> that the performance is degrading fast. UI tasks takes several >>>>>>>>> seconds >>>>>>>>> to react to my keyboard. >>>>>>>> >>>>>>>> That kind of sluggishness is probably related to finalization/gc. >>>>>>>> Please >>>>>>>> send us the result of the following expression: >>>>>>>> >>>>>>>> (WeakArray classPool at: #FinalizationDependents) >>>>>>>> select: [ :each | each notNil ] >>>>>>>> thenCollect: [ :each | each class -> each size ] >>>>>>>> >>>>>>> While updating pharo 1.2, after an EndOfCentralDirectory error, I got >>>>>>> a very unresponsive image... >>>>>>> >>>>>>> ((WeakArray classPool at: #FinalizationDependents) as: Array) >>>>>>> select: [ :each | each notNil ] >>>>>>> thenCollect: [ :each | each class -> each size] >>>>>>> -> >>>>>>> {(WeakIdentityKeyDictionary->22370). >>>>>> >>>>>> This is an MC cache. And major reason of image slowdown. >>>>>> >>>>> Levente did this simplification in trunk: >>>>> >>>>> cachedDefinitions >>>>> ^definitions ifNil: [ definitions := WeakIdentityKeyDictionary >>>>> new >>>>> ] >>>>> >>>>> It would be worth a try in Pharo. >>>> >>>> IIRC Pharo's WeakKeyDictionary (and subclasses) don't work properly if >>>> they're not registered to the finalization process. So this won't work >>>> as >>>> long as that's not fixed. >>>> >>> Huh? Can you provide a code to show it? Test case please? >>> >> Just add lots of objects which will be GC'd to an unregistered >> WeakKeyDictionary. >> After X objects are gc'd, you'd still have X nil-keyed associations in the >> dictionary. >> Add Y objects, gc those, and you have X+Y nil-keys in the dict. >> (If dict grown/rehashed, all nicely placed index 1 onwards) >> > > it doesn't sounds like incorrect behavior (i.e. pruning a nil-ed keys > before #finalizeValues could visit them). > > > It's incorrect, because WeakKeyDictionaries are not designed to be accessed > concurrently, but this can happen if the dictionary is registered to the > finalization process.
True. Another reason to not register them like MC in Pharo currently does. > It's inefficient, because someone has to send #finalizeValues, even when > there's no finalization action. > That's why in my patch, i placed #finalizeValues on finishing package load/unload actions. > > Levente > > >> Cheers, >> Henry >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
