2017-02-14 15:38 GMT+01:00 Esteban Lorenzano <[email protected]>: > > > On 14 Feb 2017, at 14:54, Pavel Krivanek <[email protected]> > wrote: > > > > Hi, > > > > It is very common to see in actively used images that the number of > instances of Point is very high. Sometimes in order of hundreds of > thousands. There is several reasons for that: > > > > Pharo every few milliseconds checks for the new display size. That check > generates two instances of Point that are not garbage collected in > reasonably short time. So if you periodically check the result of "Point > allInstances size", you will see that it is quickly growing. > > On the other hand. That Point instances are not referenced by anyone so > as soon as you do Smalltalk garbageCollect, the amount of Points in > reduced. And they are correctly garbage collected by the VM after some time > which is often longer than one minute. So no action needed. > > > > Then a lot of Points is stored in FreeTypeCache. That cache is a huge > beast and it tries to store a small form for every new rendered character > glyph. That means for every font, every pixel size etc. It sounds > reasonable but the main reason why the cache can be very huge is in the > fact that it stores a new glyph for every sub-pixel variant too! > > Every FreeTypeChacheEntry also contains several Point instances so it is > a important source of them. Fortunately, this cache has mechanisms to limit > its size. This limit now set to expected size of 5MB, see FreeTypeChache>># > defaultMaximumSize. > > So in the end, probably no immediate fix is needed although this cache > deserves revision. > > IMO, the full FT implementation needs to be revisited, both in image side > and in vm side… but this is no easy work, so… for when “there is time”… > likely never ;) > > > > > And then we have a Text related memory leak that I will try to > investigate. This memory leak does not let to garbage collect any tool > window as soon as clipboard or history (undo) was used in it. > > keep pushing! :) > (I remember there was a problem with the find&replace dialog that was a > singleton and it was keeping strong references to the (rubric) editors that > called it… maybe the leak is someplace around... >
https://pharo.fogbugz.com/f/cases/19704/Memory-leak-Clipboard-can-produce-memory-leaks And I have seen very similar memory leaks related to GLMHintableActionButtonBrick, undo managers a NECController. Maybe they are related but I need to find a way how to reproduce them. -- Pavel > > Esteban > > > > > Cheers, > > -- Pavel > > > > > > > > > > > > > > > > > > >
