implementing #release in a domain object

> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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?

> 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 <[hidden email]> 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 <[hidden email]> 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?
>

> On 06/27/2013 12:48 AM, Camillo Bruni wrote:
>>
>> On 2013-06-27, at 01:08, Paul DeBruicker <[hidden email]> 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-spoons-object-memory-visualization-tools/
>

> On 27 June 2013 21:07, Igor Stasenko <[hidden email]> 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'?