implementing #release in a domain object
Lets say I'm modeling a navy that is comprised of many ships each with their own soldiers and jobs. If I want one of the ships to be GC'd do I need to implement #release in the soldier and job objects and send it to each of those soldiers and jobs that live and work on the ship I want GC'd or is removing the references between the ship and the navy enough to have the whole ship (including its soldiers and jobs) GC'd?
There is no such thing as #release in Pharo. If you want your objects to be garbage collected just make sure to remove all references to it. You simply assign nil to instance variables which previously held such and object. Does that answer your question? On 2013-06-26, at 23:47, Paul DeBruicker <pdebruic@gmail.com> wrote:
Lets say I'm modeling a navy that is comprised of many ships each with their own soldiers and jobs. If I want one of the ships to be GC'd do I need to implement #release in the soldier and job objects and send it to each of those soldiers and jobs that live and work on the ship I want GC'd or is removing the references between the ship and the navy enough to have the whole ship (including its soldiers and jobs) GC'd?
In Pharo2 Object (and many other classes) implement #release and #release has many senders. So I don't understand how 'there is no such thing as #release in Pharo'. I understand that the GC is a VM thing and it does not send #release to the objects in the image. IF in my hypothetical question the Navy object contains an ordered collection of ships, and each ship is referenced in that collection and also by all of its soldiers and jobs, to have my ship GC'd do I only need to remove the reference to the ship in the Navy object (at which point the ship becomes detached and self contained amalgamation of soldiers and jobs) or do I have to have each soldier and job dereference the ship too? On 06/26/2013 03:05 PM, Camillo Bruni wrote:
There is no such thing as #release in Pharo. If you want your objects to be garbage collected just make sure to remove all references to it. You simply assign nil to instance variables which previously held such and object.
Does that answer your question?
On 2013-06-26, at 23:47, Paul DeBruicker <pdebruic@gmail.com> wrote:
Lets say I'm modeling a navy that is comprised of many ships each with their own soldiers and jobs. If I want one of the ships to be GC'd do I need to implement #release in the soldier and job objects and send it to each of those soldiers and jobs that live and work on the ship I want GC'd or is removing the references between the ship and the navy enough to have the whole ship (including its soldiers and jobs) GC'd?
ok I was not sure of how much you were aware of how the GC works :) second try: In your example it would be enough to cut the connection the ship, everything "aboard" will be GC'ed as well. Once you cut the connection to a subgraph of objects, and they are no longer reachable from the outside (root objects) the whole subgraph get's garbage collected. In your example: as soon as nobody references a ship anymore it gets garbage collected, as well as all objects that were only reachable via that ship. clearer? If not I suggest you quickly make your own little example. Note that with #allInstances you can see which objects are still around of a certain class, for instance: Dictionary allInstances On 2013-06-27, at 00:13, Paul DeBruicker <pdebruic@gmail.com> wrote:
In Pharo2 Object (and many other classes) implement #release and #release has many senders. So I don't understand how 'there is no such thing as #release in Pharo'. I understand that the GC is a VM thing and it does not send #release to the objects in the image.
IF in my hypothetical question the Navy object contains an ordered collection of ships, and each ship is referenced in that collection and also by all of its soldiers and jobs, to have my ship GC'd do I only need to remove the reference to the ship in the Navy object (at which point the ship becomes detached and self contained amalgamation of soldiers and jobs) or do I have to have each soldier and job dereference the ship too?
On 06/26/2013 03:05 PM, Camillo Bruni wrote:
There is no such thing as #release in Pharo. If you want your objects to be garbage collected just make sure to remove all references to it. You simply assign nil to instance variables which previously held such and object.
Does that answer your question?
On 2013-06-26, at 23:47, Paul DeBruicker <pdebruic@gmail.com> wrote:
Lets say I'm modeling a navy that is comprised of many ships each with their own soldiers and jobs. If I want one of the ships to be GC'd do I need to implement #release in the soldier and job objects and send it to each of those soldiers and jobs that live and work on the ship I want GC'd or is removing the references between the ship and the navy enough to have the whole ship (including its soldiers and jobs) GC'd?
Paul, On 26 Jun 2013, at 23:47, Paul DeBruicker <pdebruic@gmail.com> wrote:
Lets say I'm modeling a navy that is comprised of many ships each with their own soldiers and jobs. If I want one of the ships to be GC'd do I need to implement #release in the soldier and job objects and send it to each of those soldiers and jobs that live and work on the ship I want GC'd or is removing the references between the ship and the navy enough to have the whole ship (including its soldiers and jobs) GC'd?
GC is automatic memory management. Whenever something is no longer reachable by following pointers from a a know starting set, the system dictionary, the stack and some other places, it automatically becomes garbage and the memory it occupies will be reused. Of course, if you keep a reference to an object, on purpose or by accident, the object will never become garbage and it will keep on occupying memory. Especially circular references can be hard to track. There are indeed a couple of common messages that are sometimes used to break possible references by nilling out instance variables etc. #close, #stop, #unregister and indeed #release. Often, these are also used to manage external resources (open files, sockets â¦). You can use any message to do this, there is no framework that you have to follow. And then there are also finalization and weak references, which are related, but more advanced. Sven
Sven & Camillo, Ok thanks. And using the PointerFinder is there a way to know which of the pointers points to the SystemDictionary or Object someObject or whereever the GC begins so one would not have to check every pointer for every stubborn object. E.g. Lets say I've nil'ed the reference between the Navy and the ship so its ready to go but a few of the soldiers on the ship have references to other ships because their transfer papers weren't processed properly. Running #pointersTo on those soldiers gives a large collection of pointers. How can I use the computer to filter that list to just those references back to the root object? Thanks for you help Paul On 06/26/2013 03:37 PM, Sven Van Caekenberghe wrote:
Paul,
On 26 Jun 2013, at 23:47, Paul DeBruicker <pdebruic@gmail.com> wrote:
Lets say I'm modeling a navy that is comprised of many ships each with their own soldiers and jobs. If I want one of the ships to be GC'd do I need to implement #release in the soldier and job objects and send it to each of those soldiers and jobs that live and work on the ship I want GC'd or is removing the references between the ship and the navy enough to have the whole ship (including its soldiers and jobs) GC'd?
GC is automatic memory management. Whenever something is no longer reachable by following pointers from a a know starting set, the system dictionary, the stack and some other places, it automatically becomes garbage and the memory it occupies will be reused.
Of course, if you keep a reference to an object, on purpose or by accident, the object will never become garbage and it will keep on occupying memory. Especially circular references can be hard to track.
There are indeed a couple of common messages that are sometimes used to break possible references by nilling out instance variables etc. #close, #stop, #unregister and indeed #release. Often, these are also used to manage external resources (open files, sockets â¦). You can use any message to do this, there is no framework that you have to follow.
And then there are also finalization and weak references, which are related, but more advanced.
Sven
On 2013-06-27, at 01:08, Paul DeBruicker <pdebruic@gmail.com> wrote:
Sven & Camillo,
Ok thanks. And using the PointerFinder is there a way to know which of the pointers points to the SystemDictionary or Object someObject or whereever the GC begins so one would not have to check every pointer for every stubborn object.
E.g. Lets say I've nil'ed the reference between the Navy and the ship so its ready to go but a few of the soldiers on the ship have references to other ships because their transfer papers weren't processed properly. Running #pointersTo on those soldiers gives a large collection of pointers.
How can I use the computer to filter that list to just those references back to the root object?
What do you mean by root object? In any case, if I'm not mistaken, this isn't that easy. Usually you have to manually track down and follow the objects in the PointerExplorer => Inspect an Object, right click, Explore Strong Pointers
On 06/27/2013 12:48 AM, Camillo Bruni wrote:
On 2013-06-27, at 01:08, Paul DeBruicker <pdebruic@gmail.com> wrote:
Sven & Camillo,
Ok thanks. And using the PointerFinder is there a way to know which of the pointers points to the SystemDictionary or Object someObject or whereever the GC begins so one would not have to check every pointer for every stubborn object.
E.g. Lets say I've nil'ed the reference between the Navy and the ship so its ready to go but a few of the soldiers on the ship have references to other ships because their transfer papers weren't processed properly. Running #pointersTo on those soldiers gives a large collection of pointers.
How can I use the computer to filter that list to just those references back to the root object?
What do you mean by root object?
I'm sure my understanding is not completely accurate but by 'root object' I mean whichever object (memory space? pointer?) the VM always considers as part of the object-space-to-keep when it begins a full GC. So every object which is kept implicitly points to that object through a long chain (web?) of pointers.
In any case, if I'm not mistaken, this isn't that easy. Usually you have to manually track down and follow the objects in the PointerExplorer
=> Inspect an Object, right click, Explore Strong Pointers
OK. I can imagine a Roassal visualization of a rats nest of objects as nodes connected with edges made with #pointsTo: with just a few edges connecting the main blob (e.g. the navy) to objects (soldiers) in a smaller blob (the ship I want to GC). Kind of like the visualization Craig Latta uses as the header for his blog and describes here: https://thiscontext.wordpress.com/2012/10/22/a-detailed-description-of-spoon...
On 27 June 2013 14:54, Paul DeBruicker <pdebruic@gmail.com> wrote:
On 06/27/2013 12:48 AM, Camillo Bruni wrote:
On 2013-06-27, at 01:08, Paul DeBruicker <pdebruic@gmail.com> wrote:
Sven & Camillo,
Ok thanks. And using the PointerFinder is there a way to know which of the pointers points to the SystemDictionary or Object someObject or whereever the GC begins so one would not have to check every pointer for every stubborn object.
E.g. Lets say I've nil'ed the reference between the Navy and the ship so its ready to go but a few of the soldiers on the ship have references to other ships because their transfer papers weren't processed properly. Running #pointersTo on those soldiers gives a large collection of pointers.
How can I use the computer to filter that list to just those references back to the root object?
What do you mean by root object?
I'm sure my understanding is not completely accurate but by 'root object' I mean whichever object (memory space? pointer?) the VM always considers as part of the object-space-to-keep when it begins a full GC. So every object which is kept implicitly points to that object through a long chain (web?) of pointers.
yes, but in opposite direction. consider yourself a painter which start painting nodes , starting from root ones, then paint ones which they pointing to, then paint ones which those was pointing to (unless they already painted) and so on.. continue until you have nothing to paint left. Then the nodes which remain unpainted is garbage. If your objects connected via tree pattern, then everything goes well: - high command gives an order to admiral to disassemble his fleet, sink ships with all crew on board - admiral gives commands to captains, they give orders to officers and officers to rest of crew - when lower chain of command completes the order, the higher ones can commit suicide and finally captains press the button to open kingstones and die with ship. - finally admiral will do a harakiri (so, that will be perfect japanese version :) but in russian version (a graph), an admiral's dauther is married on one of the fleet's captains, and admiral, by knowing that gives order only to all but the ship where captain is in command. But that captain is friend with captain of another ship, and he asks admiral to find a way to keep that guy too and that guy can also has friends on other ships.. and so on.. so at the end, only those who has no friends will be fired.. but those who having them, will stay :)
In any case, if I'm not mistaken, this isn't that easy. Usually you have to manually track down and follow the objects in the PointerExplorer
=> Inspect an Object, right click, Explore Strong Pointers
OK. I can imagine a Roassal visualization of a rats nest of objects as nodes connected with edges made with #pointsTo: with just a few edges connecting the main blob (e.g. the navy) to objects (soldiers) in a smaller blob (the ship I want to GC). Kind of like the visualization Craig Latta uses as the header for his blog and describes here: https://thiscontext.wordpress.com/2012/10/22/a-detailed-description-of-spoon...
-- Best regards, Igor Stasenko.
Am 27.06.2013 um 21:07 schrieb Igor Stasenko <siguctua@gmail.com>:
but in russian version (a graph), an admiral's dauther is married on one of the fleet's captains, and admiral, by knowing that gives order only to all but the ship where captain is in command. But that captain is friend with captain of another ship, and he asks admiral to find a way to keep that guy too and that guy can also has friends on other ships.. and so on.. so at the end, only those who has no friends will be fired.. but those who having them, will stay :)
It will stay that way until the level of vodka supply will drop below a critical amount. What then? Implement a russian roulette GC? :) At least in Linux they did it that way and it is called OOM killer :) Norbert
On 27 June 2013 21:07, Igor Stasenko <siguctua@gmail.com> wrote:
yes, but in opposite direction. consider yourself a painter which start painting nodes , starting from root ones, then paint ones which they pointing to, then paint ones which those was pointing to (unless they already painted) and so on.. continue until you have nothing to paint left. Then the nodes which remain unpainted is garbage.
How is this implemented? There is a flag on each object to mark it as 'painted'? -- Milan Mimica http://sparklet.sf.net
On 2013-06-28, at 13:59, Milan Mimica <milan.mimica@gmail.com> wrote:
On 27 June 2013 21:07, Igor Stasenko <siguctua@gmail.com> wrote:
yes, but in opposite direction. consider yourself a painter which start painting nodes , starting from root ones, then paint ones which they pointing to, then paint ones which those was pointing to (unless they already painted) and so on.. continue until you have nothing to paint left. Then the nodes which remain unpainted is garbage.
How is this implemented? There is a flag on each object to mark it as 'painted'?
Exactly, there is a Header for each Object which contains such information only visible to the VM. You will some more information here: http://rmod.lille.inria.fr/archives/talks/2011-DIS-Stasenko-JourneyInTheVM.p...
On 28 June 2013 14:58, Camillo Bruni <camillobruni@gmail.com> wrote:
Exactly, there is a Header for each Object which contains such information only visible to the VM. You will some more information here:
http://rmod.lille.inria.fr/archives/talks/2011-DIS-Stasenko-JourneyInTheVM.p...
Interesting. I guess is has to "Stop the world"? If yes, how can it be improved? -- Milan Mimica http://sparklet.sf.net
Am 27.06.2013 um 01:07 schrieb Paul DeBruicker <pdebruic@gmail.com>:
Sven & Camillo,
Ok thanks. And using the PointerFinder is there a way to know which of the pointers points to the SystemDictionary or Object someObject or whereever the GC begins so one would not have to check every pointer for every stubborn object.
E.g. Lets say I've nil'ed the reference between the Navy and the ship so its ready to go but a few of the soldiers on the ship have references to other ships because their transfer papers weren't processed properly. Running #pointersTo on those soldiers gives a large collection of pointers.
How can I use the computer to filter that list to just those references back to the root object?
One by one. You only get the list of objects holding a pointer to the object in question. Having those objects you would need to search for pointers other objects have to them. While trying to analyze the situation it might be a good idea to do a "Smalltalk garbageCollect" in between to get rid of the objects that aren't connected but haven't garbage collected yet. Norbert
Thanks for you help
Paul
On 06/26/2013 03:37 PM, Sven Van Caekenberghe wrote:
Paul,
On 26 Jun 2013, at 23:47, Paul DeBruicker <pdebruic@gmail.com> wrote:
Lets say I'm modeling a navy that is comprised of many ships each with their own soldiers and jobs. If I want one of the ships to be GC'd do I need to implement #release in the soldier and job objects and send it to each of those soldiers and jobs that live and work on the ship I want GC'd or is removing the references between the ship and the navy enough to have the whole ship (including its soldiers and jobs) GC'd?
GC is automatic memory management. Whenever something is no longer reachable by following pointers from a a know starting set, the system dictionary, the stack and some other places, it automatically becomes garbage and the memory it occupies will be reused.
Of course, if you keep a reference to an object, on purpose or by accident, the object will never become garbage and it will keep on occupying memory. Especially circular references can be hard to track.
There are indeed a couple of common messages that are sometimes used to break possible references by nilling out instance variables etc. #close, #stop, #unregister and indeed #release. Often, these are also used to manage external resources (open files, sockets â¦). You can use any message to do this, there is no framework that you have to follow.
And then there are also finalization and weak references, which are related, but more advanced.
Sven
participants (6)
-
Camillo Bruni -
Igor Stasenko -
Milan Mimica -
Norbert Hartl -
Paul DeBruicker -
Sven Van Caekenberghe