- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Points, Free type fonts cache and memory leaks

by Esteban Lorenzano

> On 14 Feb 2017, at 14:54, Pavel Krivanek <pavel.krivanek(a)gmail.com> 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 > > > > > > > >

Feb. 14, 2017

Re: [Pharo-dev] IPv6 support [VM]

by Pierce Ng

On Tue, Feb 14, 2017 at 01:35:14PM +0100, Esteban Lorenzano wrote: > there was some work but it was not finished, then is kind of aborted (for > now). if you want to take a look there are some primitives in the networking > pluginâ¦ never finished, never tested, never done :) Should be there in the VM/plugin. I got Unix domain socket working... and I should dust off the Fogbugz issue that I created and add some tests. Pierce

Feb. 14, 2017

[ANN] Pharo Association: Join or Renew now!

by Marcus Denker

Hi, The new Pharo Association website is up and running for some month. If you are a member, it will bug you once a year to renew. If you were a member in the past and have not been bugged by the system to renew until now, please subscribe now as a new member. (We added all active members, but as the old system was purely manual, people did not get asked to renew very consistently and you might not be in the system anymore) See the website for more information: https://association.pharo.org <https://association.pharo.org/> Marcus

Feb. 14, 2017

[pharo-project/pharo-core] 77ef45: 60390

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 77ef450f7fa529837ed4c6b0bec5beba1e77d120 https://github.com/pharo-project/pharo-core/commit/77ef450f7fa529837ed4c6b0… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-14 (Tue, 14 Feb 2017) Changed paths: M Nautilus.package/AbstractNautilusUI.class/instance/build ui buttons/buildBrowseScopedButton.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60389.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60390.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60389.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60390.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Zinc-HTTP.package/ZnLogEvent.class/class/convenience/open.st Log Message: ----------- 60390 19698 Scoped button with a more meaningful tooltip https://pharo.fogbugz.com/f/cases/19698 18760 Failing test: WeakAnnouncerTest>>#testNoDeadWeakSubscriptions https://pharo.fogbugz.com/f/cases/18760 19183 ZnLogEvent open is broken https://pharo.fogbugz.com/f/cases/19183 http://files.pharo.org/image/60/60390.zip

Feb. 14, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60390 Home: https://github.com/pharo-project/pharo-core

Feb. 14, 2017

Points, Free type fonts cache and memory leaks

by Pavel Krivanek

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

Feb. 14, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60389 Home: https://github.com/pharo-project/pharo-core

Feb. 14, 2017

[pharo-project/pharo-core] b057bb: 60389

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: b057bb3e23b9828a8f0b1373c650e209254dee3a https://github.com/pharo-project/pharo-core/commit/b057bb3e23b9828a8f0b1373… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-14 (Tue, 14 Feb 2017) Changed paths: A Reflectivity-Tools.package/Watchpoint.class/instance/printing/printLastValue.st M Reflectivity-Tools.package/Watchpoint.class/instance/printing/printOn_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60388.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60389.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60388.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60389.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M SmartSuggestions.package/SugsWatchpointSuggestion.class/instance/execution/execute.st M Tests.package/SourceFileArrayTest.class/instance/testing/testProtocol.st M Tests.package/SourceFileArrayTest.class/instance/testing/testTimeStamp.st Log Message: ----------- 60389 19701 Watchpoint should not ask for name https://pharo.fogbugz.com/f/cases/19701 19700 testTimeStamp should not use hardcoded timestamp https://pharo.fogbugz.com/f/cases/19700 19699 testProtocol should not test timestamp https://pharo.fogbugz.com/f/cases/19699 http://files.pharo.org/image/60/60389.zip

Feb. 14, 2017

Re: [Pharo-dev] IPv6 support [VM]

by Esteban Lorenzano

there was some work but it was not finished, then is kind of aborted (for now). if you want to take a look there are some primitives in the networking pluginâ¦ never finished, never tested, never done :) Esteban > On 14 Feb 2017, at 13:20, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Hi, > > does anyone know what is the state of Pharo's IPv6 support? > > I've found some discussion from 2009/2010 talking about it and making changes to the VM, but it seems incomplete. > > Creating IPv6 socket seems to be supported on the VM side (and I had no failure when I modified the netType from 0 to 3 in Socket>>initialize:) > > https://github.com/pharo-project/pharo-vm/blob/master/opensmalltalk-vm/plat… > https://github.com/pharo-project/pharo-vm/blob/master/opensmalltalk-vm/plat… > > However creating connection fails I guess here > https://github.com/pharo-project/pharo-vm/blob/master/opensmalltalk-vm/src/… > > And even if it didn't fail there, sqSocketConnectToPort accepts address in sqInt (4 bytes), and sets the type to AF_INET > https://github.com/pharo-project/pharo-vm/blob/master/opensmalltalk-vm/plat… > > Was the effort abandoned? Am I doing something wrong and it actually should work? > > > Also NetNameResolver in Pharo is IPv4 only, but that's not an issue here. > > Thanks, > Peter >

Feb. 14, 2017

IPv6 support [VM]

by Peter Uhnak

Hi, does anyone know what is the state of Pharo's IPv6 support? I've found some discussion from 2009/2010 talking about it and making changes to the VM, but it seems incomplete. Creating IPv6 socket seems to be supported on the VM side (and I had no failure when I modified the netType from 0 to 3 in Socket>>initialize:) https://github.com/pharo-project/pharo-vm/blob/master/opensmalltalk-vm/plat… https://github.com/pharo-project/pharo-vm/blob/master/opensmalltalk-vm/plat… However creating connection fails I guess here https://github.com/pharo-project/pharo-vm/blob/master/opensmalltalk-vm/src/… And even if it didn't fail there, sqSocketConnectToPort accepts address in sqInt (4 bytes), and sets the type to AF_INET https://github.com/pharo-project/pharo-vm/blob/master/opensmalltalk-vm/plat… Was the effort abandoned? Am I doing something wrong and it actually should work? Also NetNameResolver in Pharo is IPv4 only, but that's not an issue here. Thanks, Peter

Feb. 14, 2017