Smalltalk › Pharo › Pharo Smalltalk Developers

Points, Free type fonts cache and memory leaks

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Pavel Krivanek-3

Points, Free type fonts cache and memory leaks

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.

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.

Cheers,

-- Pavel

EstebanLM

Re: Points, Free type fonts cache and memory leaks

> On 14 Feb 2017, at 14:54, Pavel Krivanek <[hidden email]> 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...

Esteban

>
> Cheers,
> -- Pavel
>
>
>
>
>
>
>
>

Pavel Krivanek-3

Re: Points, Free type fonts cache and memory leaks

2017-02-14 15:38 GMT+01:00 Esteban Lorenzano <[hidden email]>:

> On 14 Feb 2017, at 14:54, Pavel Krivanek <[hidden email]> 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
>
>
>
>
>
>
>
>

Ben Coman

Re: Points, Free type fonts cache and memory leaks

In reply to this post by Pavel Krivanek-3

On Tue, Feb 14, 2017 at 9:54 PM, Pavel Krivanek <[hidden email]> 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.

Even though these get cleared out, its still extra work for the GC. Presumably most of the time the display size is identical to the last one, so I wonder if the existing screen size might be passed to the primitive to test and avoid creating a new new point if its the same. Off the top of my head, something like this (untested)...

MorphicUIManager >> checkForNewDisplaySize

Display hasScreenSizeChanged ifFalse: [^ Display].

DisplayScreen startUp.

World restoreMorphicDisplay.

DisplayScreen >> hasScreenSizeChanged

^self class isActualScreenSizeX: width Y: height.

DisplayScreen class >> isActualScreenSizeX: width Y: height
<primitive: 106>

InterpreterPrimitives >> primitiveScreenSize "primitive 106"

"no arguments(original) ==> DisplayScreen_class>>actualScreenSize ; returning new Point from ioScreenSIze "

"two arguments ==> DisplayScreen_class>>isActualyScreenSizeX;Y: ; returning Boolean of whether X,Y match ioScreenSize"

| pointWord x y|

pointWord := self ioScreenSize.

x := pointWord >> 16 bitAnd: 65535.

y := pointWord bitAnd: 65535.

argumentCount = 2 ifTrue: [

((x = (self stackValue: 1)) and: [y = (self stackTop)])

ifTrue: [self pop: 3 thenPush: objectMemory trueObject]

ifFalse: [self pop: 3 thenPush: objectMemory trueObject].

self pop: 1 thenPush: (self makePointwithxValue: x yValue: y)

cheers -ben