https://pharo.fogbugz.com/default.asp?13422
I did an 'Smalltalk allClasses collect:[:cl | cl -> cl allInstances size]' before starting a load and right after a load that just does not crash the image. I noticed the following number of new instances that were still being referenced (i.e. not garbage collected). The following lists the number of _added_ instances during the load with the largest first. I include all of them but some are obviously more indicative than others. Float->3580540 Point->2149989 Rectangle->818991 Array->573089 MorphExtension->309932 TableLayoutProperties->204571 ByteString->108891 OrderedCollection->107527 IdentityDictionary->103768 ImageMorph->102338 StringMorph->102318 Morph->102313 DependentsArray->102309 TableLayout->102308 RowLayout->102259 MorphTreeNodeMorph->102252 PackageTreePackageNodeModel->102250 Association->26405 Duration->14081 CompiledMethod->11191 MethodChangeRecord->11131 IdentitySet->10843 ....
Ah ah, the return of the MorphExtensions and Floats coming from god knows where... Hope you can find the reason why. Is this related to the fact that you did a load with Nautilus open or not? Could it somehow be related to the progress bars that we see at the top left when loading? It is hard to see where things are generated, even with pointer explorers... Maybe proxying these classes could show who creates such a quantity. How does one do that? I mean creating proxies? There was Ghost, which has no really much documentation as far as I can tell. Pointers? Phil On Sun, Jun 29, 2014 at 10:38 AM, stepharo <stepharo@free.fr> wrote:
I did an 'Smalltalk allClasses collect:[:cl | cl -> cl allInstances size]' before starting a load and right after a load that just does not crash the image. I noticed the following number of new instances that were still being referenced (i.e. not garbage collected).
The following lists the number of _added_ instances during the load with the largest first. I include all of them but some are obviously more indicative than others.
Float->3580540 Point->2149989 Rectangle->818991 Array->573089 MorphExtension->309932 TableLayoutProperties->204571 ByteString->108891 OrderedCollection->107527 IdentityDictionary->103768 ImageMorph->102338 StringMorph->102318 Morph->102313 DependentsArray->102309 TableLayout->102308 RowLayout->102259 MorphTreeNodeMorph->102252 PackageTreePackageNodeModel->102250 Association->26405 Duration->14081 CompiledMethod->11191 MethodChangeRecord->11131 IdentitySet->10843 ....
What i'd be worried with is the high number of PackageTreePackageNodeModel->102250. Each node model suppose a NodeMorph, and so on... And, stef, I don't think your test was loading one hundred thousand packages, isn't it? I'd look into the package tree structure and updates. Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de stepharo [stepharo@free.fr] Envoyé : dimanche 29 juin 2014 10:38 à : Pharo Development List Objet : [Pharo-dev] https://pharo.fogbugz.com/default.asp?13422 I did an 'Smalltalk allClasses collect:[:cl | cl -> cl allInstances size]' before starting a load and right after a load that just does not crash the image. I noticed the following number of new instances that were still being referenced (i.e. not garbage collected). The following lists the number of _added_ instances during the load with the largest first. I include all of them but some are obviously more indicative than others. Float->3580540 Point->2149989 Rectangle->818991 Array->573089 MorphExtension->309932 TableLayoutProperties->204571 ByteString->108891 OrderedCollection->107527 IdentityDictionary->103768 ImageMorph->102338 StringMorph->102318 Morph->102313 DependentsArray->102309 TableLayout->102308 RowLayout->102259 MorphTreeNodeMorph->102252 PackageTreePackageNodeModel->102250 Association->26405 Duration->14081 CompiledMethod->11191 MethodChangeRecord->11131 IdentitySet->10843 ....
GOUBIER Thierry wrote:
What i'd be worried with is the high number of PackageTreePackageNodeModel->102250. Each node model suppose a NodeMorph, and so on... And, stef, I don't think your test was loading one hundred thousand packages, isn't it?
I'd look into the package tree structure and updates.
Thierry
In the past to investigate similar stuff I've used a bad hack like this... 1. In Workspace evaluate: Smalltalk at: #senders put: Bag new. 2. Define method... PackageTreePackageNodeModel class>>new | senderString | senderString := thisContext sender printString , '<--' , thisContext sender sender printString , '<--' , thisContext sender sender sender printString . "to whatever depth is useful" (Smalltalk at: #senders) add: senderString. ^ super new. I've also output the senderStrings to a log file and loaded into Excel to munge things for pattern matching. Very agricultural approach, but it turned up some results (though I can't remember what it was for.) However I've never actually plugged that sort of thing into #new, so YMMV. Also note that if you happen to step through the above code with the debugger, thisContext might not be set properly [1], although it works fine outside the debugger. [1] https://pharo.fogbugz.com/f/cases/12980/ cheers -ben
________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de stepharo [stepharo@free.fr] Envoyé : dimanche 29 juin 2014 10:38 à : Pharo Development List Objet : [Pharo-dev] https://pharo.fogbugz.com/default.asp?13422
I did an 'Smalltalk allClasses collect:[:cl | cl -> cl allInstances size]' before starting a load and right after a load that just does not crash the image. I noticed the following number of new instances that were still being referenced (i.e. not garbage collected).
The following lists the number of _added_ instances during the load with the largest first. I include all of them but some are obviously more indicative than others.
Float->3580540 Point->2149989 Rectangle->818991 Array->573089 MorphExtension->309932 TableLayoutProperties->204571 ByteString->108891 OrderedCollection->107527 IdentityDictionary->103768 ImageMorph->102338 StringMorph->102318 Morph->102313 DependentsArray->102309 TableLayout->102308 RowLayout->102259 MorphTreeNodeMorph->102252 PackageTreePackageNodeModel->102250 Association->26405 Duration->14081 CompiledMethod->11191 MethodChangeRecord->11131 IdentitySet->10843 ....
On 29 Jun 2014, at 15:24, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
What i'd be worried with is the high number of PackageTreePackageNodeModel->102250. Each node model suppose a NodeMorph, and so on... And, stef, I don't think your test was loading one hundred thousand packages, isn't it?
It was me ;-) (fogbugz sends email as Stef?) Exactly, this is where I am looking at. I have tried to find who is referencing all those instances but I have not discovered it yet.
I'd look into the package tree structure and updates.
I started to look at the single PackageTreeNautilusUI instance I have open which should be the root that is keeping all these instance in the image. But I am wandering through unknown code here... Johan
Yes, the original emal has stepharo as the sender :) Ok, I try to scan but I don't seem to reproduce. And my netbook is really slow, so scanning the memory for all instances takes forever :( Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Johan Brichau [johan@inceptive.be] Envoyé : dimanche 29 juin 2014 16:21 à : Pharo Development List Objet : Re: [Pharo-dev] https://pharo.fogbugz.com/default.asp?13422 On 29 Jun 2014, at 15:24, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
What i'd be worried with is the high number of PackageTreePackageNodeModel->102250. Each node model suppose a NodeMorph, and so on... And, stef, I don't think your test was loading one hundred thousand packages, isn't it?
It was me ;-) (fogbugz sends email as Stef?) Exactly, this is where I am looking at. I have tried to find who is referencing all those instances but I have not discovered it yet.
I'd look into the package tree structure and updates.
I started to look at the single PackageTreeNautilusUI instance I have open which should be the root that is keeping all these instance in the image. But I am wandering through unknown code here... Johan
participants (5)
-
Ben Coman -
GOUBIER Thierry -
Johan Brichau -
phil＠highoctane.be -
stepharo