My Squeak image file has been gradually expanding so that now (after about a years work) it is at 74M. (I switched to 3.8 a couple of weeks ago. The version of the image does not appear to be related to my problem.)
I checked the number of instances of each class; at the end I have posted part of the list. The largest is Array with 389647 instances. I have nothing open or active in my image except the standard windows that you get with the initial image.
Of note is ParserGenerator with 43 entries. There should be none. ParserGenerator has not had any instances created in several months. Its instances seem to be the result of being referenced by Morphs which have also not been used in months and a methodContexts which are similarly old.
Thus my image appears to have a fair number of objects that are not being garbage collected. These objects appear to be connected to either Morphs and methodContexts. (The methodContexts appear to be from doIts and compiles by instances of parserGenerator.)
I tried looking at the pointers to the parserGenerators and then the pointers to these pointers etc. but just ran in circles though I did determine that there are morphs (mostly) and methodContexts everywhere.
Are there tools that I can use to track down who is failing to break a link to these Morph and methodContext objects when they are no longer in use? In particular a tool to find a path from a global object to to a given object would be useful. Any suggestions as to what useful tools would be are welcome.
My next step is to file out all my code and then file it into a new image to free myself of the garbage. I assume all my code should be in a project but I am not sure how projects work.
Any documentation on projects anywhere?
All my code is in a system category called: '4Neufs' and all (I hope) methods that I have added to System classes are in Class category '*4Neufs'.
Thanks
Ralph Boland
Partial list in sorted order of counts of class instances (in a quiet image): (*'s class are mine)
a SortedCollection( 389647->Array 286558->Point 240405->Association 213447->Rectangle 157019->String (Some of these might be from a workspace with a lot of stuff in it) 126390->MorphExtension 103684->*N4BinaryTreeNode 99123->IdentityDictionary 62674->StringMorph 59875->CompiledMethod 54284->Float 43038->OrderedCollection 42717->Symbol 37562->RectangleMorph 34414->*N4DebugToken 33728->EventHandler etc ... 3425->BlockContext 3322->Morph 2712->TextFontChange 2519->*MenuSelectionVisibleMorph (There should be 0 of these) 2510->MenuMorph 2423->BorderedSubpaneDividerMorph 2404->Metaclass 2348->TextStyle 2317->PluggableListMorph 2267->RBMetaclass 2267->RBClass 2121->TextMorphForEditView 2110->PluggableTextMorph 2061->MethodReference 2049->InStateSemiCompact 2022->IdentitySet 2010->ClassChangeRecord 1897->SelectorNode 1651->DependentsArray 1532->StepMessage 1424->*N4IdentityHashArray (There should be 0 of these) 1412->MessageNode 1281->NoteEvent etc ... 43->ParserGenerator (There should be 0 of these) ... ~
I'm not quite sure why but I have a faint suspicion that you might have (cor, what a lot of weasel words for one sentence) a bunch of temp variable bindings being held onto by your large workspace. You could test this thesis by writing the contents out to a file and then closing the workspace. GC a few times (Smalltalk garbageCollect ) and I think you might find a lot of stuff gone.
Another place where a lot gets retained is the change sets - the old versions of the out of date methods are kept, along with all the literals etc. This is a bit different to the older changeset behaviour where just the pointer to the source code was kept. In a COPY of your image it might be worth trying destroying changesets and seeing how much gets freed up.
tim
squeak-dev@lists.squeakfoundation.org