[vwnc] Lingering Objects
Locked
 
|
I have a GUI application, where some of its instance variables are
not garbage-collected after the application is closed. The manual says that objects reachable from the system root are not removed. How do we know if objects are reachable or not. Objects are removed after aClass allInstances do: [:each | each become: String new]. Is there anything we should be careful in GUI application? Thanks Shiro Ogawa _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Before checking for #allInstances, perform "ObjectMemory
globalCompactingGC". This ensures that unreferenced objects are garbage collected. Once you find an object that you think should not be reachable (but in fact is reachable), send #allOwners to it, to get a list of objects referring it. Since you have the debugger operating on the unwanted object, many references from the inspector will be shown. You can create statements like this to avoid opening the inspector: MyClassWhichShouldHaveNoInstances allInstances first allOwners inspect Usually the kind of problem you describe can happen as a result of a dependency from the UI to the domain. You might need to disconnect dependencies when the UI is closed. Read "Trigger-Event System" in the Application Developer's Guide and "Adapting Domain Models to Widgets" in the "GUI Developer's Guide" for more information. Do a search for "Removing Event Handlers",and see if that gives some clue. You might want to describe in more detail what you do. Is it so that for example the domain object is still in memory after closing the UI? If so, is the UI still in memory too? One thing to remember is that the object engine in VisualWorks is rock solid. These problems very seldom stem from a problem in Cincom's code. Kind regards Runar Jordahl 2008/12/17 Shiro Ogawa <[hidden email]>: > I have a GUI application, where some of its instance variables are > not garbage-collected after the application is closed. The manual says > that objects reachable from the system root are not removed. How do we > know if objects are reachable or not. Objects are removed after > > aClass allInstances do: [:each | each become: String new]. > > Is there anything we should be careful in GUI application? > > Thanks > > Shiro Ogawa > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Runar, thanks for a quick response. In my case, UI is not in the
memory, but the domain model remains. This is in development environment. I am worried about what would happend in the deployed application environment. I will check the link between UI and the domain. Shiro On Tue, Dec 16, 2008 at 11:51 PM, Runar Jordahl <[hidden email]> wrote: > Before checking for #allInstances, perform "ObjectMemory > globalCompactingGC". This ensures that unreferenced objects are > garbage collected. > > Once you find an object that you think should not be reachable (but in > fact is reachable), send #allOwners to it, to get a list of objects > referring it. > > Since you have the debugger operating on the unwanted object, many > references from the inspector will be shown. You can create statements > like this to avoid opening the inspector: > > MyClassWhichShouldHaveNoInstances allInstances first allOwners inspect > > Usually the kind of problem you describe can happen as a result of a > dependency from the UI to the domain. You might need to disconnect > dependencies when the UI is closed. Read "Trigger-Event System" in the > Application Developer's Guide and "Adapting Domain Models to Widgets" > in the "GUI Developer's Guide" for more information. Do a search for > "Removing Event Handlers",and see if that gives some clue. > > You might want to describe in more detail what you do. Is it so that > for example the domain object is still in memory after closing the UI? > If so, is the UI still in memory too? > > One thing to remember is that the object engine in VisualWorks is rock > solid. These problems very seldom stem from a problem in Cincom's > code. > > Kind regards > Runar Jordahl > > > > 2008/12/17 Shiro Ogawa <[hidden email]>: >> I have a GUI application, where some of its instance variables are >> not garbage-collected after the application is closed. The manual says >> that objects reachable from the system root are not removed. How do we >> know if objects are reachable or not. Objects are removed after >> >> aClass allInstances do: [:each | each become: String new]. >> >> Is there anything we should be careful in GUI application? >> >> Thanks >> >> Shiro Ogawa >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Just a simple hint:
VisualWorks provides a much more powerful feature to analyze references to objects. If you load Advanced Tools (at least parcel "AT System Analysis") you will find a new menu item "Inspect Reference Paths" in the Inspector. This will find all possible reference paths from root to an object. The result is a collection of paths, each of them an OrderedCollection of objects building the chain from somewhere to your lingering object. Shiro Ogawa schrieb: > Runar, thanks for a quick response. In my case, UI is not in the > memory, but the domain model remains. This is in development > environment. I am worried about what would happend in the deployed > application environment. I will check the link between UI and the > domain. > > Shiro > > On Tue, Dec 16, 2008 at 11:51 PM, Runar Jordahl <[hidden email]> wrote: > >> Before checking for #allInstances, perform "ObjectMemory >> globalCompactingGC". This ensures that unreferenced objects are >> garbage collected. >> >> Once you find an object that you think should not be reachable (but in >> fact is reachable), send #allOwners to it, to get a list of objects >> referring it. >> >> Since you have the debugger operating on the unwanted object, many >> references from the inspector will be shown. You can create statements >> like this to avoid opening the inspector: >> >> MyClassWhichShouldHaveNoInstances allInstances first allOwners inspect >> >> Usually the kind of problem you describe can happen as a result of a >> dependency from the UI to the domain. You might need to disconnect >> dependencies when the UI is closed. Read "Trigger-Event System" in the >> Application Developer's Guide and "Adapting Domain Models to Widgets" >> in the "GUI Developer's Guide" for more information. Do a search for >> "Removing Event Handlers",and see if that gives some clue. >> >> You might want to describe in more detail what you do. Is it so that >> for example the domain object is still in memory after closing the UI? >> If so, is the UI still in memory too? >> >> One thing to remember is that the object engine in VisualWorks is rock >> solid. These problems very seldom stem from a problem in Cincom's >> code. >> >> Kind regards >> Runar Jordahl >> >> >> >> 2008/12/17 Shiro Ogawa <[hidden email]>: >> >>> I have a GUI application, where some of its instance variables are >>> not garbage-collected after the application is closed. The manual says >>> that objects reachable from the system root are not removed. How do we >>> know if objects are reachable or not. Objects are removed after >>> >>> aClass allInstances do: [:each | each become: String new]. >>> >>> Is there anything we should be careful in GUI application? >>> >>> Thanks >>> >>> Shiro Ogawa >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>> >>> > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > Holger Guhl -- Senior Consultant * Certified Scrum Master * [hidden email] Tel: +49 231 9 75 99 21 * Fax: +49 231 9 75 99 20 Georg Heeg eK Dortmund Handelsregister: Amtsgericht Dortmund A 12812 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Runar Jordahl
Runar Jordahl wrote:
> Before checking for #allInstances, perform "ObjectMemory > globalCompactingGC". This ensures that unreferenced objects are > garbage collected. > Not always, some objects need to be finalized before they will let go of further objects. The package 'ForceFinalization' in the public repository will allow you to repeatedly collect garbage until no more objects get finalized. (It adds some items to the launchers 'system' menu). As it happens it contains some code that I like very much, it demonstrates the power of implementing queries on blockclosure: finalizeDeeply "Repeatedly collect garbage until no objects finalize any more. Skip perm space" "ObjectMemory finalizeDeeply" [[self garbageCollect] finalizesObjects] whileTrue More comment than code :-) R - _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Shiro Ogawa
One reason domain objects linger around is because they
are in the Dependents dictionary. From the VisualLauncher do Browse->Inspect->DependentsFields. If you find any of your domain objects in the dictionary you should make them a subclass of Model or add a dependents ivar and the myDependents(:) accessors. While VisualWorks will let you do an addDependent to any object, it really is not good form to rely on the dependents fields dictionary. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Shiro Ogawa > Sent: Wednesday, December 17, 2008 4:04 AM > To: Runar Jordahl > Cc: [hidden email] > Subject: Re: [vwnc] Lingering Objects > > Runar, thanks for a quick response. In my case, UI is not in the > memory, but the domain model remains. This is in development > environment. I am worried about what would happend in the deployed > application environment. I will check the link between UI and the > domain. > > Shiro > > On Tue, Dec 16, 2008 at 11:51 PM, Runar Jordahl <[hidden email]> wrote: > > Before checking for #allInstances, perform "ObjectMemory > > globalCompactingGC". This ensures that unreferenced objects are > > garbage collected. > > > > Once you find an object that you think should not be reachable (but in > > fact is reachable), send #allOwners to it, to get a list of objects > > referring it. > > > > Since you have the debugger operating on the unwanted object, many > > references from the inspector will be shown. You can create statements > > like this to avoid opening the inspector: > > > > MyClassWhichShouldHaveNoInstances allInstances first allOwners inspect > > > > Usually the kind of problem you describe can happen as a result of a > > dependency from the UI to the domain. You might need to disconnect > > dependencies when the UI is closed. Read "Trigger-Event System" in the > > Application Developer's Guide and "Adapting Domain Models to Widgets" > > in the "GUI Developer's Guide" for more information. Do a search for > > "Removing Event Handlers",and see if that gives some clue. > > > > You might want to describe in more detail what you do. Is it so that > > for example the domain object is still in memory after closing the UI? > > If so, is the UI still in memory too? > > > > One thing to remember is that the object engine in VisualWorks is rock > > solid. These problems very seldom stem from a problem in Cincom's > > code. > > > > Kind regards > > Runar Jordahl > > > > > > > > 2008/12/17 Shiro Ogawa <[hidden email]>: > >> I have a GUI application, where some of its instance variables are > >> not garbage-collected after the application is closed. The manual says > >> that objects reachable from the system root are not removed. How do we > >> know if objects are reachable or not. Objects are removed after > >> > >> aClass allInstances do: [:each | each become: String new]. > >> > >> Is there anything we should be careful in GUI application? > >> > >> Thanks > >> > >> Shiro Ogawa > >> _______________________________________________ > >> vwnc mailing list > >> [hidden email] > >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > >> > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Hi all,
I have an imga with a package "Convenience". In Comment tab, there is this: "This package is a set of methods that should be defined in the VisualWorks base or are methods that we use commonly across all programs - even core or utility programs." But I have not this package in my others images. Do you know its origin ? Thanks a lot. Jannik _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
That package exists in the public repository, published by
Michael Lucas-Smith. Given the comment, I suspect that it comes from a
previous job, since Michael now works for Cincom and has an inside track
on defining things in the VisualWorks base. Its only use appears to be in
the Twitter bundle.
At 07:55 AM 12/17/2008, Laval Jannik wrote: Hi all, --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by jannik laval
ok,
Thanks a lot. Jannik Le 17 déc. 08 à 15:24, Alan Knight a écrit :
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by jannik laval
it is part of the prerequisites of the Linkuistics package from the public store.
2008/12/17 Laval Jannik <[hidden email]> Hi all, _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Lingering Objects
|
|
In reply to this post by Shiro Ogawa
Shiro:
In a development environment, where a developer saves the image, all kinds of things get "stuck" and hang around. Those objects are no longer reachable by application logic, but can be held as artifacts of programming mistakes. It is certainly good to try to minimize that. However, in my experience, you don't deploy UI client images that allow for the user to save the actual state of that image. So, it is *somewhat* less of a concern to have a few garbage objects hanging around during a working session with that deployed application. When the image is restarted, the garbage is gone. Of course, if your application is a server, like SWAZOO as an example, it is much more critical, because the server image is running for long periods of time. If you continue to accumulate uncollectible garbage, you have a big problem. Good Luck!! On Dec 17, 2008, at 1:04 AM, Shiro Ogawa wrote: > Runar, thanks for a quick response. In my case, UI is not in the > memory, but the domain model remains. This is in development > environment. I am worried about what would happend in the deployed > application environment. I will check the link between UI and the > domain. > > Shiro > > On Tue, Dec 16, 2008 at 11:51 PM, Runar Jordahl <[hidden email] > > wrote: >> Before checking for #allInstances, perform "ObjectMemory >> globalCompactingGC". This ensures that unreferenced objects are >> garbage collected. >> >> Once you find an object that you think should not be reachable (but >> in >> fact is reachable), send #allOwners to it, to get a list of objects >> referring it. >> >> Since you have the debugger operating on the unwanted object, many >> references from the inspector will be shown. You can create >> statements >> like this to avoid opening the inspector: >> >> MyClassWhichShouldHaveNoInstances allInstances first allOwners >> inspect >> >> Usually the kind of problem you describe can happen as a result of a >> dependency from the UI to the domain. You might need to disconnect >> dependencies when the UI is closed. Read "Trigger-Event System" in >> the >> Application Developer's Guide and "Adapting Domain Models to Widgets" >> in the "GUI Developer's Guide" for more information. Do a search for >> "Removing Event Handlers",and see if that gives some clue. >> >> You might want to describe in more detail what you do. Is it so that >> for example the domain object is still in memory after closing the >> UI? >> If so, is the UI still in memory too? >> >> One thing to remember is that the object engine in VisualWorks is >> rock >> solid. These problems very seldom stem from a problem in Cincom's >> code. >> >> Kind regards >> Runar Jordahl >> >> >> >> 2008/12/17 Shiro Ogawa <[hidden email]>: >>> I have a GUI application, where some of its instance variables are >>> not garbage-collected after the application is closed. The manual >>> says >>> that objects reachable from the system root are not removed. How >>> do we >>> know if objects are reachable or not. Objects are removed after >>> >>> aClass allInstances do: [:each | each become: String new]. >>> >>> Is there anything we should be careful in GUI application? >>> >>> Thanks >>> >>> Shiro Ogawa >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>> >> > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc Thanks!! Joseph Bacanskas [|] --- I use Smalltalk. My amp goes to eleven. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Shiro Ogawa
Thanks, everybody for kind advices. I found that the UI (subclass of
ApplicationModel) was kept because there was a circular reference between the UI and its subcanvas (The subcanvas has the main UI in its IV, and the subcanvas is the IV of the main UI). Setting the IV of the subcanvas to nil before closing the main window cleared all. Probably this does not matter in deployment environment as Joseph said because only one main UI is open for the life time of the application. Shiro Ogawa _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Shiro Ogawa wrote:
> Thanks, everybody for kind advices. I found that the UI (subclass of > ApplicationModel) was kept because there was a circular reference > between the UI and its subcanvas (The subcanvas has the main UI in its > IV, and the subcanvas is the IV of the main UI). The VisualWorks garbage collectors have no problem handling garbage objects with circular references. So when you say > Setting the IV of the > subcanvas to nil before closing the main window cleared all. I fear that you only solved half of your problem, the main UI may have been released now but I guess your subcanvas has not been garbage collected yet. R - > Probably > this does not matter in deployment environment as Joseph said because > only one main UI is open for the life time of the application. > > Shiro Ogawa > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > -- ********************************************************************* Dit e-mailbericht is alleen bestemd voor de geadresseerde(n). Gebruik door anderen is niet toegestaan. Indien u niet degeadresseerde(n) bent wordt u verzocht de verzender hiervan op de hoogte te stellen en het bericht te verwijderen. Door de elektronische verzending kunnen aan de inhoud van dit bericht geen rechten worden ontleend. Soops B.V. is gevestigd te Amsterdam, Nederland, en is geregistreerd bij de Kamer van Koophandel onder nummer 33240368. Soops B.V. levert volgens de Fenit voorwaarden, gedeponeerd te Den Haag op 8 december 1994 onder nummer 1994/189. ********************************************************************** This e-mail message is intended to be exclusively for the addressee. If you are not the intended recipient you are kindly requested not to make any use whatsoever of the contents and to notify the sender immediately by returning this e-mail message. No rights can be derived from this message. Soops B.V. is a private limited liability company and has its seat at Amsterdam, The Netherlands and is registered with the Trade Registry of the Chamber of Commerce and Industry under number 33240368. Soops B.V. delivers according to the General Terms and Conditions of Business of Fenit, registered at The Hague, The Netherlands on December 8th, 1994, under number 1994/189 ********************************************************************** _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Shiro Ogawa
Hi Shiro,
A possibility for your memory leak can be an undeclared variable. Perhaps the variable holding your subcanvas is undeclared? You can check undeclared variables easily by going to the VisualWorks launcher and then Browse>Inspect>Undeclared. This opens an inspector containing all variables that haven't been declared and you can browse references to them. If your subcanvas instvar (or another one) is in there, it may well be the cause for the leak. Just declaring the variable in the appropriate place fixes the problem. As Reinout said, it would be very strange that your memory leak would be fixed by nilling the instvar holding the subcanvas. Mark -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Shiro Ogawa Sent: donderdag 18 december 2008 4:00 To: [hidden email] Subject: Re: [vwnc] Lingering Objects Thanks, everybody for kind advices. I found that the UI (subclass of ApplicationModel) was kept because there was a circular reference between the UI and its subcanvas (The subcanvas has the main UI in its IV, and the subcanvas is the IV of the main UI). Setting the IV of the subcanvas to nil before closing the main window cleared all. Probably this does not matter in deployment environment as Joseph said because only one main UI is open for the life time of the application. Shiro Ogawa _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Terry Raymond
In your application model be sure to use instances of List as Model for
SequenceViews, Trees, etc. not e.g. OrderedCollection, as the last produce these entries in the DependentFields while Lists manage dependencies by their own which can be cleaned up more easily. To support the garbage collector by breaking cycles you can also add a #release method to your applicationModel class that cleans up aspects. This release could be called on noticeOfWindowClose for example (this depends on you application logic) Thomas Terry Raymond schrieb: > One reason domain objects linger around is because they > are in the Dependents dictionary. From the VisualLauncher > do Browse->Inspect->DependentsFields. > > If you find any of your domain objects in the dictionary > you should make them a subclass of Model or add a dependents > ivar and the myDependents(:) accessors. While VisualWorks will > let you do an addDependent to any object, it really is not > good form to rely on the dependents fields dictionary. > > Terry > > =========================================================== > Terry Raymond > Crafted Smalltalk > 80 Lazywood Ln. > Tiverton, RI 02878 > (401) 624-4517 [hidden email] > <http://www.craftedsmalltalk.com> > =========================================================== > >> -----Original Message----- >> From: [hidden email] [mailto:[hidden email]] On Behalf Of Shiro Ogawa >> Sent: Wednesday, December 17, 2008 4:04 AM >> To: Runar Jordahl >> Cc: [hidden email] >> Subject: Re: [vwnc] Lingering Objects >> >> Runar, thanks for a quick response. In my case, UI is not in the >> memory, but the domain model remains. This is in development >> environment. I am worried about what would happend in the deployed >> application environment. I will check the link between UI and the >> domain. >> >> Shiro >> >> On Tue, Dec 16, 2008 at 11:51 PM, Runar Jordahl <[hidden email]> wrote: >> >>> Before checking for #allInstances, perform "ObjectMemory >>> globalCompactingGC". This ensures that unreferenced objects are >>> garbage collected. >>> >>> Once you find an object that you think should not be reachable (but in >>> fact is reachable), send #allOwners to it, to get a list of objects >>> referring it. >>> >>> Since you have the debugger operating on the unwanted object, many >>> references from the inspector will be shown. You can create statements >>> like this to avoid opening the inspector: >>> >>> MyClassWhichShouldHaveNoInstances allInstances first allOwners inspect >>> >>> Usually the kind of problem you describe can happen as a result of a >>> dependency from the UI to the domain. You might need to disconnect >>> dependencies when the UI is closed. Read "Trigger-Event System" in the >>> Application Developer's Guide and "Adapting Domain Models to Widgets" >>> in the "GUI Developer's Guide" for more information. Do a search for >>> "Removing Event Handlers",and see if that gives some clue. >>> >>> You might want to describe in more detail what you do. Is it so that >>> for example the domain object is still in memory after closing the UI? >>> If so, is the UI still in memory too? >>> >>> One thing to remember is that the object engine in VisualWorks is rock >>> solid. These problems very seldom stem from a problem in Cincom's >>> code. >>> >>> Kind regards >>> Runar Jordahl >>> >>> >>> >>> 2008/12/17 Shiro Ogawa <[hidden email]>: >>> >>>> I have a GUI application, where some of its instance variables are >>>> not garbage-collected after the application is closed. The manual says >>>> that objects reachable from the system root are not removed. How do we >>>> know if objects are reachable or not. Objects are removed after >>>> >>>> aClass allInstances do: [:each | each become: String new]. >>>> >>>> Is there anything we should be careful in GUI application? >>>> >>>> Thanks >>>> >>>> Shiro Ogawa >>>> _______________________________________________ >>>> vwnc mailing list >>>> [hidden email] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>> >>>> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Shiro Ogawa
As Mark predicted, the subcanvas had an undeclared IV.
When that was fixed, without nilling the IV, all the UI objects are cleared. I really did not understand what was going. Thanks again everybody. Shiro Ogawa _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |