Hi, There seems to be some kind of memory leak in recent Pharo 4.0 images. Image size (as saved on disk) seems to be growing very rapidly under normal use (development with Nautilus, Spotter, GTPlayground, GTInspector and Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and they seem to increase constantly, over a period of days. One way to look at memory use is with SpaceTally printSpaceAnalysis but that takes a while. Please help us find and fix this issue. Thanks, Sven
On 24 Mar 2015, at 15:18, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi,
There seems to be some kind of memory leak in recent Pharo 4.0 images. Image size (as saved on disk) seems to be growing very rapidly under normal use (development with Nautilus, Spotter, GTPlayground, GTInspector and Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and they seem to increase constantly, over a period of days.
Are you saying that the static image size is growing? Dynamic growth could easily be explained by leaks in NativeBoost for instance. But static image size means that there are objects lying around that shouldnât (at least that should be easier to debug).
One way to look at memory use is with
SpaceTally printSpaceAnalysis
but that takes a while.
Please help us find and fix this issue.
Thanks,
Sven
On 24 Mar 2015, at 16:13, Max Leske <maxleske@gmail.com> wrote:
On 24 Mar 2015, at 15:18, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi,
There seems to be some kind of memory leak in recent Pharo 4.0 images. Image size (as saved on disk) seems to be growing very rapidly under normal use (development with Nautilus, Spotter, GTPlayground, GTInspector and Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and they seem to increase constantly, over a period of days.
Are you saying that the static image size is growing? Dynamic growth could easily be explained by leaks in NativeBoost for instance. But static image size means that there are objects lying around that shouldnât (at least that should be easier to debug).
Yes, it is the latter. We have seen it in a couple of places, but we can't seem to find the culprit. Many people do not keep images very long, but it seems to be visible in one to two days, which is obviously too fast.
One way to look at memory use is with
SpaceTally printSpaceAnalysis
but that takes a while.
Please help us find and fix this issue.
Thanks,
Sven
Yes, there are clearly objects lying around. I suspect it has to do with Playground or Inspector, but I am not sure. Doru On Tue, Mar 24, 2015 at 4:13 PM, Max Leske <maxleske@gmail.com> wrote:
On 24 Mar 2015, at 15:18, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi,
There seems to be some kind of memory leak in recent Pharo 4.0 images. Image size (as saved on disk) seems to be growing very rapidly under normal use (development with Nautilus, Spotter, GTPlayground, GTInspector and Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and they seem to increase constantly, over a period of days.
Are you saying that the static image size is growing? Dynamic growth could easily be explained by leaks in NativeBoost for instance. But static image size means that there are objects lying around that shouldnât (at least that should be easier to debug).
One way to look at memory use is with
SpaceTally printSpaceAnalysis
but that takes a while.
Please help us find and fix this issue.
Thanks,
Sven
-- www.tudorgirba.com "Every thing has its own flow"
There are lot of spotter objects that do not get garbaged collected GTSpotter allInstances size --> 29 in my image On Tue, Mar 24, 2015 at 4:16 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Yes, there are clearly objects lying around. I suspect it has to do with Playground or Inspector, but I am not sure.
Doru
On Tue, Mar 24, 2015 at 4:13 PM, Max Leske <maxleske@gmail.com> wrote:
On 24 Mar 2015, at 15:18, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi,
There seems to be some kind of memory leak in recent Pharo 4.0 images. Image size (as saved on disk) seems to be growing very rapidly under normal use (development with Nautilus, Spotter, GTPlayground, GTInspector and Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and they seem to increase constantly, over a period of days.
Are you saying that the static image size is growing? Dynamic growth could easily be explained by leaks in NativeBoost for instance. But static image size means that there are objects lying around that shouldnât (at least that should be easier to debug).
One way to look at memory use is with
SpaceTally printSpaceAnalysis
but that takes a while.
Please help us find and fix this issue.
Thanks,
Sven
-- www.tudorgirba.com
"Every thing has its own flow"
On 24 Mar 2015, at 16:50, Andrei Chis <chisvasileandrei@gmail.com> wrote:
There are lot of spotter objects that do not get garbaged collected
GTSpotter allInstances size --> 29 in my image
I got 10 now. But can they cause megabytes to be locked up ?
On Tue, Mar 24, 2015 at 4:16 PM, Tudor Girba <tudor@tudorgirba.com> wrote: Yes, there are clearly objects lying around. I suspect it has to do with Playground or Inspector, but I am not sure.
Doru
On Tue, Mar 24, 2015 at 4:13 PM, Max Leske <maxleske@gmail.com> wrote:
On 24 Mar 2015, at 15:18, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi,
There seems to be some kind of memory leak in recent Pharo 4.0 images. Image size (as saved on disk) seems to be growing very rapidly under normal use (development with Nautilus, Spotter, GTPlayground, GTInspector and Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and they seem to increase constantly, over a period of days.
Are you saying that the static image size is growing? Dynamic growth could easily be explained by leaks in NativeBoost for instance. But static image size means that there are objects lying around that shouldnât (at least that should be easier to debug).
One way to look at memory use is with
SpaceTally printSpaceAnalysis
but that takes a while.
Please help us find and fix this issue.
Thanks,
Sven
-- www.tudorgirba.com
"Every thing has its own flow"
On 24 Mar 2015, at 16:56, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 24 Mar 2015, at 16:50, Andrei Chis <chisvasileandrei@gmail.com> wrote:
There are lot of spotter objects that do not get garbaged collected
GTSpotter allInstances size --> 29 in my image
I got 10 now.
But can they cause megabytes to be locked up ?
If they work like Nautilus then thereâs a huge tree attached to every one, with morphs, weak references, contexts⦠I think there was (and maybe there still is) a problem with detection of circular dependencies and weak references. If you register actions in the EventManager (or whatever itâs called now) make sure that they are cleared. Then, there used to be a class variable somewhere that held on to the single instance of some kind of work space factory (or some such thing) which strongly holds on to stuff and prevents garbage collection. I donât know what has been cleaned by now but thereâs a lot of potential for such things⦠I had to write some code a while ago to get rid of window instances that wouldnât be garbage collected. Iâve attached the file outs, maybe someone can use them (they are for Pharo 1.3 though, so maybe not of too much useâ¦) Cheers, Max
On Tue, Mar 24, 2015 at 4:16 PM, Tudor Girba <tudor@tudorgirba.com> wrote: Yes, there are clearly objects lying around. I suspect it has to do with Playground or Inspector, but I am not sure.
Doru
On Tue, Mar 24, 2015 at 4:13 PM, Max Leske <maxleske@gmail.com> wrote:
On 24 Mar 2015, at 15:18, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi,
There seems to be some kind of memory leak in recent Pharo 4.0 images. Image size (as saved on disk) seems to be growing very rapidly under normal use (development with Nautilus, Spotter, GTPlayground, GTInspector and Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and they seem to increase constantly, over a period of days.
Are you saying that the static image size is growing? Dynamic growth could easily be explained by leaks in NativeBoost for instance. But static image size means that there are objects lying around that shouldnât (at least that should be easier to debug).
One way to look at memory use is with
SpaceTally printSpaceAnalysis
but that takes a while.
Please help us find and fix this issue.
Thanks,
Sven
-- www.tudorgirba.com
"Every thing has its own flow"
2015-03-24 17:22 GMT+01:00 Max Leske <maxleske@gmail.com>:
On 24 Mar 2015, at 16:56, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 24 Mar 2015, at 16:50, Andrei Chis <chisvasileandrei@gmail.com> wrote:
There are lot of spotter objects that do not get garbaged collected
GTSpotter allInstances size --> 29 in my image
I got 10 now.
But can they cause megabytes to be locked up ?
If they work like Nautilus then thereâs a huge tree attached to every one, with morphs, weak references, contexts⦠I think there was (and maybe there still is) a problem with detection of circular dependencies and weak references. If you register actions in the EventManager (or whatever itâs called now) make sure that they are cleared.
Then, there used to be a class variable somewhere that held on to the single instance of some kind of work space factory (or some such thing) which strongly holds on to stuff and prevents garbage collection.
I donât know what has been cleaned by now but thereâs a lot of potential for such thingsâ¦
I had to write some code a while ago to get rid of window instances that wouldnât be garbage collected. Iâve attached the file outs, maybe someone can use them (they are for Pharo 1.3 though, so maybe not of too much useâ¦)
Cheers, Max
it sounds similar to http://lists.squeakfoundation.org/pipermail/beginners/2008-July/004731.html If we have some WeakKeyAssociation, but the same key is also used on the value side, then we never reclaim... But we wouldn't do that, would we? Well we did... http://bugs.squeak.org/view.php?id=7119 Nicolas
On Tue, Mar 24, 2015 at 4:16 PM, Tudor Girba <tudor@tudorgirba.com>
wrote:
Yes, there are clearly objects lying around. I suspect it has to do with Playground or Inspector, but I am not sure.
Doru
On Tue, Mar 24, 2015 at 4:13 PM, Max Leske <maxleske@gmail.com> wrote:
On 24 Mar 2015, at 15:18, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi,
There seems to be some kind of memory leak in recent Pharo 4.0 images. Image size (as saved on disk) seems to be growing very rapidly under normal use (development with Nautilus, Spotter, GTPlayground, GTInspector and Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and they seem to increase constantly, over a period of days.
Are you saying that the static image size is growing? Dynamic growth could easily be explained by leaks in NativeBoost for instance. But static image size means that there are objects lying around that shouldnât (at least that should be easier to debug).
One way to look at memory use is with
SpaceTally printSpaceAnalysis
but that takes a while.
Please help us find and fix this issue.
Thanks,
Sven
-- www.tudorgirba.com
"Every thing has its own flow"
Along the lines of Nicolas' hint, here's one example of what you can *not* do, and expect to work (just the other way around): GLMPagerScrollBrick pagerModel: aModel pagerModel := aModel. -snip- pagerModel announcer weak when: GLMPagePushed send: #onPagePushed: to: self. -snip- In a workspace: pager:= GLMPagerModel new. brick := GLMPagerScrollBrick new. brick pagerModel: pager. brick := nil. Smalltalk garbageCollect. pager announcer subscriptions numberOfSubscriptions. --> 8 And, with a small addition of early exit after nilling pagerModel if aModel is nil: (pager announcer subscriptions instVarNamed: #subscriptions) anyOne subscriber pagerModel: nil. Smalltalk garbageCollect. pager announcer subscriptions numberOfSubscriptions. --> 0 In other words: You can NOT hold references to Announcers in an object that subscribes to it weakly. Cheers, Henry -- View this message in context: http://forum.world.st/Some-Memory-Leak-tp4814779p4814906.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
A tiny bit of code review while I'm at it... GTSpotterResultsBrick >> initialize super initialize self band hSpaceFill. self announcer weak subscribe: GLMBrickScrollPositionChanged send: #onScrolled to: self This is a tempting, but sneaky anti-pattern, you should never, ever, ever have to subscribe to your own announcer: The reason for calling it an anti-pattern is; if your code actually depends on this, it means other sources might invoke changes in you indirectly through your announcer, which quickly becomes debugging hell if you allow it, and something screws up. (I speak from experience) It's much easier to understand when done directly, in this case that means extending the super method where announcement is made: GTSpotterResultsBrick >> privateScrollPosition:anInteger super privateScrollPosition:anInteger. self onScrolled Cheers, Henry P.S. Announcements are objects, they are intended to hold the data subscribers might be interested in. Whenever you find yourself writing something like: someAnnouncer announce: SomeAnnouncement new ask yourself twice if that may lead to subscribers accessing state that would more naturally be part of the announcement through other channels (such as keeping extra instvars, etc). -- View this message in context: http://forum.world.st/Some-Memory-Leak-tp4814779p4814912.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi Henry, Thanks for the feedback. Don't stop :) In this case I think the memory lead comes from the class variables of GLMHintableActionButtonBrick. Clearing them up removes all instances of playground and spotter from my image. We need to find a better design for that. Cheers, Andrei On Tue, Mar 24, 2015 at 9:38 PM, Henrik Sperre Johansen < henrik.s.johansen@veloxit.no> wrote:
A tiny bit of code review while I'm at it...
GTSpotterResultsBrick >> initialize super initialize self band hSpaceFill. self announcer weak subscribe: GLMBrickScrollPositionChanged send: #onScrolled to: self
This is a tempting, but sneaky anti-pattern, you should never, ever, ever have to subscribe to your own announcer: The reason for calling it an anti-pattern is; if your code actually depends on this, it means other sources might invoke changes in you indirectly through your announcer, which quickly becomes debugging hell if you allow it, and something screws up. (I speak from experience)
It's much easier to understand when done directly, in this case that means extending the super method where announcement is made:
GTSpotterResultsBrick >> privateScrollPosition:anInteger super privateScrollPosition:anInteger. self onScrolled
Cheers, Henry
P.S. Announcements are objects, they are intended to hold the data subscribers might be interested in. Whenever you find yourself writing something like: someAnnouncer announce: SomeAnnouncement new ask yourself twice if that may lead to subscribers accessing state that would more naturally be part of the announcement through other channels (such as keeping extra instvars, etc).
-- View this message in context: http://forum.world.st/Some-Memory-Leak-tp4814779p4814912.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi henrik your analyses are great. What do you think about GTSpotterStep>>#candidates ^ candidates ifNil: [ candidates := GTSpotterCandidatesList new. candidates announcer weak subscribe: GTSpotterCandidateAdded do: [ self candidates hasOnlyOneItem ifTrue: [ self selectFirst ] ]. candidates announcer weak subscribe: GTSpotterAllCandidatesAdded do: [ self selectFirst ]. candidates announcer weak subscribe: GTSpotterAllCandidatesRemoved do: [ self selected: nil ]. candidates ] Le 24/3/15 21:38, Henrik Sperre Johansen a écrit :
A tiny bit of code review while I'm at it...
GTSpotterResultsBrick >> initialize super initialize self band hSpaceFill. self announcer weak subscribe: GLMBrickScrollPositionChanged send: #onScrolled to: self
This is a tempting, but sneaky anti-pattern, you should never, ever, ever have to subscribe to your own announcer: The reason for calling it an anti-pattern is; if your code actually depends on this, it means other sources might invoke changes in you indirectly through your announcer, which quickly becomes debugging hell if you allow it, and something screws up. (I speak from experience)
It's much easier to understand when done directly, in this case that means extending the super method where announcement is made:
GTSpotterResultsBrick >> privateScrollPosition:anInteger super privateScrollPosition:anInteger. self onScrolled
Cheers, Henry
P.S. Announcements are objects, they are intended to hold the data subscribers might be interested in. Whenever you find yourself writing something like: someAnnouncer announce: SomeAnnouncement new ask yourself twice if that may lead to subscribers accessing state that would more naturally be part of the announcement through other channels (such as keeping extra instvars, etc).
-- View this message in context: http://forum.world.st/Some-Memory-Leak-tp4814779p4814912.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Up to now, we identified two issues that lead to objects not being garbage collected: - GLMHintableActionButtonBrick triggers a singleton asynctask that was not cleaned after the task was ready. Now, that problem should be solved in GT. - RubFindReplaceService has a Singleton class variable. At the same time, RubFindReplaceService also keeps a reference to the textArea which is part of the morph tree and will prevent the whole UI that includes it to be garbage collected. We are working on dealing with this issue. There might be other issues. We need to keep looking. Cheers, Doru On Wed, Mar 25, 2015 at 8:52 AM, stepharo <stepharo@free.fr> wrote:
Hi henrik
your analyses are great. What do you think about
GTSpotterStep>>#candidates
^ candidates ifNil: [ candidates := GTSpotterCandidatesList new. candidates announcer weak subscribe: GTSpotterCandidateAdded do: [ self candidates hasOnlyOneItem ifTrue: [ self selectFirst ] ]. candidates announcer weak subscribe: GTSpotterAllCandidatesAdded do: [ self selectFirst ]. candidates announcer weak subscribe: GTSpotterAllCandidatesRemoved do: [ self selected: nil ]. candidates ]
Le 24/3/15 21:38, Henrik Sperre Johansen a écrit :
A tiny bit of code review while I'm at it...
GTSpotterResultsBrick >> initialize super initialize self band hSpaceFill. self announcer weak subscribe: GLMBrickScrollPositionChanged send: #onScrolled to: self
This is a tempting, but sneaky anti-pattern, you should never, ever, ever have to subscribe to your own announcer: The reason for calling it an anti-pattern is; if your code actually depends on this, it means other sources might invoke changes in you indirectly through your announcer, which quickly becomes debugging hell if you allow it, and something screws up. (I speak from experience)
It's much easier to understand when done directly, in this case that means extending the super method where announcement is made:
GTSpotterResultsBrick >> privateScrollPosition:anInteger super privateScrollPosition:anInteger. self onScrolled
Cheers, Henry
P.S. Announcements are objects, they are intended to hold the data subscribers might be interested in. Whenever you find yourself writing something like: someAnnouncer announce: SomeAnnouncement new ask yourself twice if that may lead to subscribers accessing state that would more naturally be part of the announcement through other channels (such as keeping extra instvars, etc).
-- View this message in context: http://forum.world.st/Some- Memory-Leak-tp4814779p4814912.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com "Every thing has its own flow"
Please tell us when this gets integrated so that we can test the effect. Or to go faster, please give some instructions (an executable expression) that we can execute in the latest image to load the relevant changes. We need more eyeballs.
On 25 Mar 2015, at 09:50, Tudor Girba <tudor@tudorgirba.com> wrote:
Up to now, we identified two issues that lead to objects not being garbage collected:
- GLMHintableActionButtonBrick triggers a singleton asynctask that was not cleaned after the task was ready. Now, that problem should be solved in GT.
- RubFindReplaceService has a Singleton class variable. At the same time, RubFindReplaceService also keeps a reference to the textArea which is part of the morph tree and will prevent the whole UI that includes it to be garbage collected. We are working on dealing with this issue.
There might be other issues. We need to keep looking.
Cheers, Doru
On Wed, Mar 25, 2015 at 8:52 AM, stepharo <stepharo@free.fr> wrote: Hi henrik
your analyses are great. What do you think about
GTSpotterStep>>#candidates
^ candidates ifNil: [ candidates := GTSpotterCandidatesList new. candidates announcer weak subscribe: GTSpotterCandidateAdded do: [ self candidates hasOnlyOneItem ifTrue: [ self selectFirst ] ]. candidates announcer weak subscribe: GTSpotterAllCandidatesAdded do: [ self selectFirst ]. candidates announcer weak subscribe: GTSpotterAllCandidatesRemoved do: [ self selected: nil ]. candidates ]
Le 24/3/15 21:38, Henrik Sperre Johansen a écrit :
A tiny bit of code review while I'm at it...
GTSpotterResultsBrick >> initialize super initialize self band hSpaceFill. self announcer weak subscribe: GLMBrickScrollPositionChanged send: #onScrolled to: self
This is a tempting, but sneaky anti-pattern, you should never, ever, ever have to subscribe to your own announcer: The reason for calling it an anti-pattern is; if your code actually depends on this, it means other sources might invoke changes in you indirectly through your announcer, which quickly becomes debugging hell if you allow it, and something screws up. (I speak from experience)
It's much easier to understand when done directly, in this case that means extending the super method where announcement is made:
GTSpotterResultsBrick >> privateScrollPosition:anInteger super privateScrollPosition:anInteger. self onScrolled
Cheers, Henry
P.S. Announcements are objects, they are intended to hold the data subscribers might be interested in. Whenever you find yourself writing something like: someAnnouncer announce: SomeAnnouncement new ask yourself twice if that may lead to subscribers accessing state that would more naturally be part of the announcement through other channels (such as keeping extra instvars, etc).
-- View this message in context: http://forum.world.st/Some-Memory-Leak-tp4814779p4814912.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
To load the latest version in an image execute: { { 'ConfigurationOfRubric'. 'AlainPlantec'. 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGToolkitCore'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer new smalltalkhubUser: spec second project: spec third; package: spec first; load ]. ConfigurationOfGToolkitCore loadDevelopment. Then run cleanUp: Smalltalk cleanUp: true except: #() confirming: false. Now only the latest instance of playground/spotter is not garbaged collected, but that would be fixed very soon. Cheers, Andrei On Wed, Mar 25, 2015 at 11:21 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Please tell us when this gets integrated so that we can test the effect.
Or to go faster, please give some instructions (an executable expression) that we can execute in the latest image to load the relevant changes.
We need more eyeballs.
On 25 Mar 2015, at 09:50, Tudor Girba <tudor@tudorgirba.com> wrote:
Up to now, we identified two issues that lead to objects not being garbage collected:
- GLMHintableActionButtonBrick triggers a singleton asynctask that was not cleaned after the task was ready. Now, that problem should be solved in GT.
- RubFindReplaceService has a Singleton class variable. At the same time, RubFindReplaceService also keeps a reference to the textArea which is part of the morph tree and will prevent the whole UI that includes it to be garbage collected. We are working on dealing with this issue.
There might be other issues. We need to keep looking.
Cheers, Doru
On Wed, Mar 25, 2015 at 8:52 AM, stepharo <stepharo@free.fr> wrote: Hi henrik
your analyses are great. What do you think about
GTSpotterStep>>#candidates
^ candidates ifNil: [ candidates := GTSpotterCandidatesList new. candidates announcer weak subscribe: GTSpotterCandidateAdded do: [ self candidates hasOnlyOneItem ifTrue: [ self selectFirst ] ]. candidates announcer weak subscribe: GTSpotterAllCandidatesAdded do: [ self selectFirst ]. candidates announcer weak subscribe: GTSpotterAllCandidatesRemoved do: [ self selected: nil ]. candidates ]
Le 24/3/15 21:38, Henrik Sperre Johansen a écrit :
A tiny bit of code review while I'm at it...
GTSpotterResultsBrick >> initialize super initialize self band hSpaceFill. self announcer weak subscribe: GLMBrickScrollPositionChanged send: #onScrolled to: self
This is a tempting, but sneaky anti-pattern, you should never, ever, ever have to subscribe to your own announcer: The reason for calling it an anti-pattern is; if your code actually depends on this, it means other sources might invoke changes in you indirectly through your announcer, which quickly becomes debugging hell if you allow it, and something screws up. (I speak from experience)
It's much easier to understand when done directly, in this case that means extending the super method where announcement is made:
GTSpotterResultsBrick >> privateScrollPosition:anInteger super privateScrollPosition:anInteger. self onScrolled
Cheers, Henry
P.S. Announcements are objects, they are intended to hold the data subscribers might be interested in. Whenever you find yourself writing something like: someAnnouncer announce: SomeAnnouncement new ask yourself twice if that may lead to subscribers accessing state that would more naturally be part of the announcement through other channels (such as keeping extra instvars, etc).
-- View this message in context: http://forum.world.st/Some-Memory-Leak-tp4814779p4814912.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
YES! My image went from 65Mb to 34Mb (it contains Seaside/Bootstrap and several resources). Thanks a lot, you guys (and everybody else who contributes) rock! Let's hope this solves the issue.
On 25 Mar 2015, at 11:26, Andrei Chis <chisvasileandrei@gmail.com> wrote:
To load the latest version in an image execute:
{ { 'ConfigurationOfRubric'. 'AlainPlantec'. 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGToolkitCore'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer new smalltalkhubUser: spec second project: spec third; package: spec first; load ]. ConfigurationOfGToolkitCore loadDevelopment.
Then run cleanUp:
Smalltalk cleanUp: true except: #() confirming: false.
Now only the latest instance of playground/spotter is not garbaged collected, but that would be fixed very soon.
Cheers, Andrei
On Wed, Mar 25, 2015 at 11:21 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote: Please tell us when this gets integrated so that we can test the effect.
Or to go faster, please give some instructions (an executable expression) that we can execute in the latest image to load the relevant changes.
We need more eyeballs.
On 25 Mar 2015, at 09:50, Tudor Girba <tudor@tudorgirba.com> wrote:
Up to now, we identified two issues that lead to objects not being garbage collected:
- GLMHintableActionButtonBrick triggers a singleton asynctask that was not cleaned after the task was ready. Now, that problem should be solved in GT.
- RubFindReplaceService has a Singleton class variable. At the same time, RubFindReplaceService also keeps a reference to the textArea which is part of the morph tree and will prevent the whole UI that includes it to be garbage collected. We are working on dealing with this issue.
There might be other issues. We need to keep looking.
Cheers, Doru
On Wed, Mar 25, 2015 at 8:52 AM, stepharo <stepharo@free.fr> wrote: Hi henrik
your analyses are great. What do you think about
GTSpotterStep>>#candidates
^ candidates ifNil: [ candidates := GTSpotterCandidatesList new. candidates announcer weak subscribe: GTSpotterCandidateAdded do: [ self candidates hasOnlyOneItem ifTrue: [ self selectFirst ] ]. candidates announcer weak subscribe: GTSpotterAllCandidatesAdded do: [ self selectFirst ]. candidates announcer weak subscribe: GTSpotterAllCandidatesRemoved do: [ self selected: nil ]. candidates ]
Le 24/3/15 21:38, Henrik Sperre Johansen a écrit :
A tiny bit of code review while I'm at it...
GTSpotterResultsBrick >> initialize super initialize self band hSpaceFill. self announcer weak subscribe: GLMBrickScrollPositionChanged send: #onScrolled to: self
This is a tempting, but sneaky anti-pattern, you should never, ever, ever have to subscribe to your own announcer: The reason for calling it an anti-pattern is; if your code actually depends on this, it means other sources might invoke changes in you indirectly through your announcer, which quickly becomes debugging hell if you allow it, and something screws up. (I speak from experience)
It's much easier to understand when done directly, in this case that means extending the super method where announcement is made:
GTSpotterResultsBrick >> privateScrollPosition:anInteger super privateScrollPosition:anInteger. self onScrolled
Cheers, Henry
P.S. Announcements are objects, they are intended to hold the data subscribers might be interested in. Whenever you find yourself writing something like: someAnnouncer announce: SomeAnnouncement new ask yourself twice if that may lead to subscribers accessing state that would more naturally be part of the announcement through other channels (such as keeping extra instvars, etc).
-- View this message in context: http://forum.world.st/Some-Memory-Leak-tp4814779p4814912.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
+1 Le 25/3/15 11:52, Sven Van Caekenberghe a écrit :
YES!
My image went from 65Mb to 34Mb (it contains Seaside/Bootstrap and several resources).
Thanks a lot, you guys (and everybody else who contributes) rock!
Let's hope this solves the issue.
On 25 Mar 2015, at 11:26, Andrei Chis <chisvasileandrei@gmail.com> wrote:
To load the latest version in an image execute:
{ { 'ConfigurationOfRubric'. 'AlainPlantec'. 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGToolkitCore'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer new smalltalkhubUser: spec second project: spec third; package: spec first; load ]. ConfigurationOfGToolkitCore loadDevelopment.
Then run cleanUp:
Smalltalk cleanUp: true except: #() confirming: false.
Now only the latest instance of playground/spotter is not garbaged collected, but that would be fixed very soon.
Cheers, Andrei
On Wed, Mar 25, 2015 at 11:21 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote: Please tell us when this gets integrated so that we can test the effect.
Or to go faster, please give some instructions (an executable expression) that we can execute in the latest image to load the relevant changes.
We need more eyeballs.
On 25 Mar 2015, at 09:50, Tudor Girba <tudor@tudorgirba.com> wrote:
Up to now, we identified two issues that lead to objects not being garbage collected:
- GLMHintableActionButtonBrick triggers a singleton asynctask that was not cleaned after the task was ready. Now, that problem should be solved in GT.
- RubFindReplaceService has a Singleton class variable. At the same time, RubFindReplaceService also keeps a reference to the textArea which is part of the morph tree and will prevent the whole UI that includes it to be garbage collected. We are working on dealing with this issue.
There might be other issues. We need to keep looking.
Cheers, Doru
On Wed, Mar 25, 2015 at 8:52 AM, stepharo <stepharo@free.fr> wrote: Hi henrik
your analyses are great. What do you think about
GTSpotterStep>>#candidates
^ candidates ifNil: [ candidates := GTSpotterCandidatesList new. candidates announcer weak subscribe: GTSpotterCandidateAdded do: [ self candidates hasOnlyOneItem ifTrue: [ self selectFirst ] ]. candidates announcer weak subscribe: GTSpotterAllCandidatesAdded do: [ self selectFirst ]. candidates announcer weak subscribe: GTSpotterAllCandidatesRemoved do: [ self selected: nil ]. candidates ]
Le 24/3/15 21:38, Henrik Sperre Johansen a écrit :
A tiny bit of code review while I'm at it...
GTSpotterResultsBrick >> initialize super initialize self band hSpaceFill. self announcer weak subscribe: GLMBrickScrollPositionChanged send: #onScrolled to: self
This is a tempting, but sneaky anti-pattern, you should never, ever, ever have to subscribe to your own announcer: The reason for calling it an anti-pattern is; if your code actually depends on this, it means other sources might invoke changes in you indirectly through your announcer, which quickly becomes debugging hell if you allow it, and something screws up. (I speak from experience)
It's much easier to understand when done directly, in this case that means extending the super method where announcement is made:
GTSpotterResultsBrick >> privateScrollPosition:anInteger super privateScrollPosition:anInteger. self onScrolled
Cheers, Henry
P.S. Announcements are objects, they are intended to hold the data subscribers might be interested in. Whenever you find yourself writing something like: someAnnouncer announce: SomeAnnouncement new ask yourself twice if that may lead to subscribers accessing state that would more naturally be part of the announcement through other channels (such as keeping extra instvars, etc).
-- View this message in context: http://forum.world.st/Some-Memory-Leak-tp4814779p4814912.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
Now, with Alain's help, also the memory leak from Rubric is solved. All fixes will be in the next version, which will hopefully be ready today. Cheers, Andrei On Wed, Mar 25, 2015 at 7:05 PM, stepharo <stepharo@free.fr> wrote:
+1
Le 25/3/15 11:52, Sven Van Caekenberghe a écrit :
YES!
My image went from 65Mb to 34Mb (it contains Seaside/Bootstrap and several resources).
Thanks a lot, you guys (and everybody else who contributes) rock!
Let's hope this solves the issue.
On 25 Mar 2015, at 11:26, Andrei Chis <chisvasileandrei@gmail.com>
wrote:
To load the latest version in an image execute:
{ { 'ConfigurationOfRubric'. 'AlainPlantec'. 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGToolkitCore'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer new smalltalkhubUser: spec second project: spec third; package: spec first; load ]. ConfigurationOfGToolkitCore loadDevelopment.
Then run cleanUp:
Smalltalk cleanUp: true except: #() confirming: false.
Now only the latest instance of playground/spotter is not garbaged collected, but that would be fixed very soon.
Cheers, Andrei
On Wed, Mar 25, 2015 at 11:21 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote: Please tell us when this gets integrated so that we can test the effect.
Or to go faster, please give some instructions (an executable expression) that we can execute in the latest image to load the relevant changes.
We need more eyeballs.
On 25 Mar 2015, at 09:50, Tudor Girba <tudor@tudorgirba.com> wrote:
Up to now, we identified two issues that lead to objects not being garbage collected:
- GLMHintableActionButtonBrick triggers a singleton asynctask that was not cleaned after the task was ready. Now, that problem should be solved in GT.
- RubFindReplaceService has a Singleton class variable. At the same time, RubFindReplaceService also keeps a reference to the textArea which is part of the morph tree and will prevent the whole UI that includes it to be garbage collected. We are working on dealing with this issue.
There might be other issues. We need to keep looking.
Cheers, Doru
On Wed, Mar 25, 2015 at 8:52 AM, stepharo <stepharo@free.fr> wrote: Hi henrik
your analyses are great. What do you think about
GTSpotterStep>>#candidates
^ candidates ifNil: [ candidates := GTSpotterCandidatesList new. candidates announcer weak subscribe: GTSpotterCandidateAdded do: [ self candidates hasOnlyOneItem ifTrue: [ self selectFirst ] ]. candidates announcer weak subscribe: GTSpotterAllCandidatesAdded do: [ self selectFirst ]. candidates announcer weak subscribe: GTSpotterAllCandidatesRemoved do: [ self selected: nil ]. candidates ]
Le 24/3/15 21:38, Henrik Sperre Johansen a écrit :
A tiny bit of code review while I'm at it...
GTSpotterResultsBrick >> initialize super initialize self band hSpaceFill. self announcer weak subscribe: GLMBrickScrollPositionChanged send: #onScrolled to: self
This is a tempting, but sneaky anti-pattern, you should never, ever, ever have to subscribe to your own announcer: The reason for calling it an anti-pattern is; if your code actually depends on this, it means other sources might invoke changes in you indirectly through your announcer, which quickly becomes debugging hell if you allow it, and something screws up. (I speak from experience)
It's much easier to understand when done directly, in this case that means extending the super method where announcement is made:
GTSpotterResultsBrick >> privateScrollPosition:anInteger super privateScrollPosition:anInteger. self onScrolled
Cheers, Henry
P.S. Announcements are objects, they are intended to hold the data subscribers might be interested in. Whenever you find yourself writing something like: someAnnouncer announce: SomeAnnouncement new ask yourself twice if that may lead to subscribers accessing state that would more naturally be part of the announcement through other channels (such as keeping extra instvars, etc).
-- View this message in context: http://forum.world.st/Some- Memory-Leak-tp4814779p4814912.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
Wow!
On 26 Mar 2015, at 14:24, Andrei Chis <chisvasileandrei@gmail.com> wrote:
Now, with Alain's help, also the memory leak from Rubric is solved. All fixes will be in the next version, which will hopefully be ready today.
Cheers, Andrei
On Wed, Mar 25, 2015 at 7:05 PM, stepharo <stepharo@free.fr> wrote: +1
Le 25/3/15 11:52, Sven Van Caekenberghe a écrit :
YES!
My image went from 65Mb to 34Mb (it contains Seaside/Bootstrap and several resources).
Thanks a lot, you guys (and everybody else who contributes) rock!
Let's hope this solves the issue.
On 25 Mar 2015, at 11:26, Andrei Chis <chisvasileandrei@gmail.com> wrote:
To load the latest version in an image execute:
{ { 'ConfigurationOfRubric'. 'AlainPlantec'. 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGToolkitCore'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer new smalltalkhubUser: spec second project: spec third; package: spec first; load ]. ConfigurationOfGToolkitCore loadDevelopment.
Then run cleanUp:
Smalltalk cleanUp: true except: #() confirming: false.
Now only the latest instance of playground/spotter is not garbaged collected, but that would be fixed very soon.
Cheers, Andrei
On Wed, Mar 25, 2015 at 11:21 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote: Please tell us when this gets integrated so that we can test the effect.
Or to go faster, please give some instructions (an executable expression) that we can execute in the latest image to load the relevant changes.
We need more eyeballs.
On 25 Mar 2015, at 09:50, Tudor Girba <tudor@tudorgirba.com> wrote:
Up to now, we identified two issues that lead to objects not being garbage collected:
- GLMHintableActionButtonBrick triggers a singleton asynctask that was not cleaned after the task was ready. Now, that problem should be solved in GT.
- RubFindReplaceService has a Singleton class variable. At the same time, RubFindReplaceService also keeps a reference to the textArea which is part of the morph tree and will prevent the whole UI that includes it to be garbage collected. We are working on dealing with this issue.
There might be other issues. We need to keep looking.
Cheers, Doru
On Wed, Mar 25, 2015 at 8:52 AM, stepharo <stepharo@free.fr> wrote: Hi henrik
your analyses are great. What do you think about
GTSpotterStep>>#candidates
^ candidates ifNil: [ candidates := GTSpotterCandidatesList new. candidates announcer weak subscribe: GTSpotterCandidateAdded do: [ self candidates hasOnlyOneItem ifTrue: [ self selectFirst ] ]. candidates announcer weak subscribe: GTSpotterAllCandidatesAdded do: [ self selectFirst ]. candidates announcer weak subscribe: GTSpotterAllCandidatesRemoved do: [ self selected: nil ]. candidates ]
Le 24/3/15 21:38, Henrik Sperre Johansen a écrit :
A tiny bit of code review while I'm at it...
GTSpotterResultsBrick >> initialize super initialize self band hSpaceFill. self announcer weak subscribe: GLMBrickScrollPositionChanged send: #onScrolled to: self
This is a tempting, but sneaky anti-pattern, you should never, ever, ever have to subscribe to your own announcer: The reason for calling it an anti-pattern is; if your code actually depends on this, it means other sources might invoke changes in you indirectly through your announcer, which quickly becomes debugging hell if you allow it, and something screws up. (I speak from experience)
It's much easier to understand when done directly, in this case that means extending the super method where announcement is made:
GTSpotterResultsBrick >> privateScrollPosition:anInteger super privateScrollPosition:anInteger. self onScrolled
Cheers, Henry
P.S. Announcements are objects, they are intended to hold the data subscribers might be interested in. Whenever you find yourself writing something like: someAnnouncer announce: SomeAnnouncement new ask yourself twice if that may lead to subscribers accessing state that would more naturally be part of the announcement through other channels (such as keeping extra instvars, etc).
-- View this message in context: http://forum.world.st/Some-Memory-Leak-tp4814779p4814912.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
This is really great! Le 26/3/15 14:24, Andrei Chis a écrit :
Now, with Alain's help, also the memory leak from Rubric is solved. All fixes will be in the next version, which will hopefully be ready today.
Cheers, Andrei
On Wed, Mar 25, 2015 at 7:05 PM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
+1
Le 25/3/15 11:52, Sven Van Caekenberghe a écrit :
YES!
My image went from 65Mb to 34Mb (it contains Seaside/Bootstrap and several resources).
Thanks a lot, you guys (and everybody else who contributes) rock!
Let's hope this solves the issue.
On 25 Mar 2015, at 11:26, Andrei Chis <chisvasileandrei@gmail.com <mailto:chisvasileandrei@gmail.com>> wrote:
To load the latest version in an image execute:
{ { 'ConfigurationOfRubric'. 'AlainPlantec'. 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGToolkitCore'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer new smalltalkhubUser: spec second project: spec third; package: spec first; load ]. ConfigurationOfGToolkitCore loadDevelopment.
Then run cleanUp:
Smalltalk cleanUp: true except: #() confirming: false.
Now only the latest instance of playground/spotter is not garbaged collected, but that would be fixed very soon.
Cheers, Andrei
On Wed, Mar 25, 2015 at 11:21 AM, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> wrote: Please tell us when this gets integrated so that we can test the effect.
Or to go faster, please give some instructions (an executable expression) that we can execute in the latest image to load the relevant changes.
We need more eyeballs.
On 25 Mar 2015, at 09:50, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote:
Up to now, we identified two issues that lead to objects not being garbage collected:
- GLMHintableActionButtonBrick triggers a singleton asynctask that was not cleaned after the task was ready. Now, that problem should be solved in GT.
- RubFindReplaceService has a Singleton class variable. At the same time, RubFindReplaceService also keeps a reference to the textArea which is part of the morph tree and will prevent the whole UI that includes it to be garbage collected. We are working on dealing with this issue.
There might be other issues. We need to keep looking.
Cheers, Doru
On Wed, Mar 25, 2015 at 8:52 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote: Hi henrik
your analyses are great. What do you think about
GTSpotterStep>>#candidates
^ candidates ifNil: [ candidates := GTSpotterCandidatesList new. candidates announcer weak subscribe: GTSpotterCandidateAdded do: [ self candidates hasOnlyOneItem ifTrue: [ self selectFirst ] ]. candidates announcer weak subscribe: GTSpotterAllCandidatesAdded do: [ self selectFirst ]. candidates announcer weak subscribe: GTSpotterAllCandidatesRemoved do: [ self selected: nil ]. candidates ]
Le 24/3/15 21:38, Henrik Sperre Johansen a écrit :
A tiny bit of code review while I'm at it...
GTSpotterResultsBrick >> initialize super initialize self band hSpaceFill. self announcer weak subscribe: GLMBrickScrollPositionChanged send: #onScrolled to: self
This is a tempting, but sneaky anti-pattern, you should never, ever, ever have to subscribe to your own announcer: The reason for calling it an anti-pattern is; if your code actually depends on this, it means other sources might invoke changes in you indirectly through your announcer, which quickly becomes debugging hell if you allow it, and something screws up. (I speak from experience)
It's much easier to understand when done directly, in this case that means extending the super method where announcement is made:
GTSpotterResultsBrick >> privateScrollPosition:anInteger super privateScrollPosition:anInteger. self onScrolled
Cheers, Henry
P.S. Announcements are objects, they are intended to hold the data subscribers might be interested in. Whenever you find yourself writing something like: someAnnouncer announce: SomeAnnouncement new ask yourself twice if that may lead to subscribers accessing state that would more naturally be part of the announcement through other channels (such as keeping extra instvars, etc).
-- View this message in context: http://forum.world.st/Some-Memory-Leak-tp4814779p4814912.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
Thanks! Thanks! Thanks! Le 25/3/15 09:50, Tudor Girba a écrit :
Up to now, we identified two issues that lead to objects not being garbage collected:
- GLMHintableActionButtonBrick triggers a singleton asynctask that was not cleaned after the task was ready. Now, that problem should be solved in GT.
- RubFindReplaceService has a Singleton class variable. At the same time, RubFindReplaceService also keeps a reference to the textArea which is part of the morph tree and will prevent the whole UI that includes it to be garbage collected. We are working on dealing with this issue.
There might be other issues. We need to keep looking.
Cheers, Doru
On Wed, Mar 25, 2015 at 8:52 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Hi henrik
your analyses are great. What do you think about
GTSpotterStep>>#candidates
^ candidates ifNil: [ candidates := GTSpotterCandidatesList new. candidates announcer weak subscribe: GTSpotterCandidateAdded do: [ self candidates hasOnlyOneItem ifTrue: [ self selectFirst ] ]. candidates announcer weak subscribe: GTSpotterAllCandidatesAdded do: [ self selectFirst ]. candidates announcer weak subscribe: GTSpotterAllCandidatesRemoved do: [ self selected: nil ]. candidates ]
Le 24/3/15 21:38, Henrik Sperre Johansen a écrit :
A tiny bit of code review while I'm at it...
GTSpotterResultsBrick >> initialize super initialize self band hSpaceFill. self announcer weak subscribe: GLMBrickScrollPositionChanged send: #onScrolled to: self
This is a tempting, but sneaky anti-pattern, you should never, ever, ever have to subscribe to your own announcer: The reason for calling it an anti-pattern is; if your code actually depends on this, it means other sources might invoke changes in you indirectly through your announcer, which quickly becomes debugging hell if you allow it, and something screws up. (I speak from experience)
It's much easier to understand when done directly, in this case that means extending the super method where announcement is made:
GTSpotterResultsBrick >> privateScrollPosition:anInteger super privateScrollPosition:anInteger. self onScrolled
Cheers, Henry
P.S. Announcements are objects, they are intended to hold the data subscribers might be interested in. Whenever you find yourself writing something like: someAnnouncer announce: SomeAnnouncement new ask yourself twice if that may lead to subscribers accessing state that would more naturally be part of the announcement through other channels (such as keeping extra instvars, etc).
-- View this message in context: http://forum.world.st/Some-Memory-Leak-tp4814779p4814912.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
If somebody has a larger image can he/she load the latest version of Glamour-Morphic-Brick and then run [1] plus a few garbage collects. [1] Smalltalk cleanUp: true except: #() confirming: false. Cheers, Andrei On Tue, Mar 24, 2015 at 4:56 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 24 Mar 2015, at 16:50, Andrei Chis <chisvasileandrei@gmail.com> wrote:
There are lot of spotter objects that do not get garbaged collected
GTSpotter allInstances size --> 29 in my image
I got 10 now.
But can they cause megabytes to be locked up ?
On Tue, Mar 24, 2015 at 4:16 PM, Tudor Girba <tudor@tudorgirba.com> wrote: Yes, there are clearly objects lying around. I suspect it has to do with Playground or Inspector, but I am not sure.
Doru
On Tue, Mar 24, 2015 at 4:13 PM, Max Leske <maxleske@gmail.com> wrote:
On 24 Mar 2015, at 15:18, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi,
There seems to be some kind of memory leak in recent Pharo 4.0 images. Image size (as saved on disk) seems to be growing very rapidly under normal use (development with Nautilus, Spotter, GTPlayground, GTInspector and Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and they seem to increase constantly, over a period of days.
Are you saying that the static image size is growing? Dynamic growth could easily be explained by leaks in NativeBoost for instance. But static image size means that there are objects lying around that shouldnât (at least that should be easier to debug).
One way to look at memory use is with
SpaceTally printSpaceAnalysis
but that takes a while.
Please help us find and fix this issue.
Thanks,
Sven
-- www.tudorgirba.com
"Every thing has its own flow"
I also tried this: 1. Create a dummy class: Object subclass: #AAA instanceVariableNames: 'x' classVariableNames: '' category: 'AAA'. 2. Open a Playground and do it and go on this: a := #AAA asClass new. 3. In the second pane go on "self" 4. Close the Playground 5. Execute: 3 timesRepeat: [ Smalltalk garbageCollect ]. 6. Check: #AAA asClass allInstances. 7. Repeat if necessary, and after a while, the result after step 6 is not empty. Cheers, Doru On Tue, Mar 24, 2015 at 4:50 PM, Andrei Chis <chisvasileandrei@gmail.com> wrote:
There are lot of spotter objects that do not get garbaged collected
GTSpotter allInstances size --> 29 in my image
On Tue, Mar 24, 2015 at 4:16 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Yes, there are clearly objects lying around. I suspect it has to do with Playground or Inspector, but I am not sure.
Doru
On Tue, Mar 24, 2015 at 4:13 PM, Max Leske <maxleske@gmail.com> wrote:
On 24 Mar 2015, at 15:18, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi,
There seems to be some kind of memory leak in recent Pharo 4.0 images. Image size (as saved on disk) seems to be growing very rapidly under normal use (development with Nautilus, Spotter, GTPlayground, GTInspector and Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and they seem to increase constantly, over a period of days.
Are you saying that the static image size is growing? Dynamic growth could easily be explained by leaks in NativeBoost for instance. But static image size means that there are objects lying around that shouldnât (at least that should be easier to debug).
One way to look at memory use is with
SpaceTally printSpaceAnalysis
but that takes a while.
Please help us find and fix this issue.
Thanks,
Sven
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
participants (7)
-
Andrei Chis -
Henrik Sperre Johansen -
Max Leske -
Nicolas Cellier -
stepharo -
Sven Van Caekenberghe -
Tudor Girba