Scanning objects

Hi Pierre,

Nice work on the visualizations! In GemStone (as with any Smalltalk), one is sometimes faced with the question, “Why is my image (or repository) growing?” If you are intentionally adding data to a record, then that’s fine, but if you are expecting a “steady-state” then growth would be unexpected. For example, if your application design is to remove tickets when they are closed, then you would expect a (fairly) stable system.

Given the object graph nature of Smalltalk, things will be garbage-collected if they are not reachable from a persistent root (in Pharo it is the SmalltalkImage singleton or the SystemDictionary in globals; in GemStone it is AllUsers). Thus, the question, “Why is my image/repository growing?” has a simple answer: “Because there are objects that aren’t being garbage-collected!” The question, “Why aren’t these objects being garbage-collected?” also has a simple answer: “Because they are reachable from a persistent root!” 

This suggests the question, “What are the path(s) to some objects that I think should not be referenced?” That is, I’ve removed them from my master collection (say, OpenTickets), but they still exist in the image/repository. Typically what we find is that in an effort to optimize some lookup, we keep a cache of references. For example, I want to know which tickets an employee is handling. Instead of iterating over all the tickets (which could take more time), I have a collection of assigned tickets in the employee object. If I remove an object from the master collection, it doesn’t automatically get removed from the employee’s active list. 

By running the method #’findAllReferencePathsToObjects:limitObjArray:printToLog:’, you find that a ticket is held by a collection that is held by an employee. This brings you to the realization that you forgot to remove tickets from the employee’s active list when they are closed. That is a typical use of this method.

James

On Mar 26, 2015, at 6:10 AM, Pierre CHANSON <[hidden email]> wrote:

Hi James,

ok I understand know that using this method you are supposed to have a bunch of objects that you know you don't need to exceed in the scan.

I have this very quick video to explain what I am doing, the scan method is used arround 2:30 https://vimeo.com/123261640

So I was more in going from an object to another without limit, but I was not well aware of the real uses.

Would you have some example of common uses with this method ?

Thanks :)

Pierre

2015-03-25 22:23 GMT-03:00 James Foster <[hidden email]>:

I’m not sure I understand the question. The first argument, the object list, is the collection of objects for which to search. The second argument, the limit collection, tells the system to stop searching backwards when it reaches one of these objects. Thus, you will have an answer of paths from each of the objects in the first collection to each of the objects in the second collection.

Finding all references to every object is an unusual request. What are you trying to accomplish? Usually you have a handful of objects and are wondering, “Why isn’t this getting garbage collected?” This method helps with that. 

James

On Mar 25, 2015, at 6:14 PM, Pierre CHANSON via GemStone-Smalltalk <[hidden email]> wrote:

Hi everyone,

I am working with the interesting method:

Repository>>findAllReferencePathsToObjects:limitObjArray:printToLog:

and I actually have troubles to define the limitObjArray, how can I increase it from the default one ? for example on every Objects of my gemstone ?

Thank you,

Pierre

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

As mentioned earlier, there is always an ultimate root, so the question of picking a stoping point is really not so important. If you leave it out then the reference chain will always start with the following:

AllUsers->aUserProfile->aSymbolList->aSymbolDictionary->aSymbolAssociation

From the SymbolAssociation you know the name of the global that is in the reference path, and knowledge of your domain should be enough to get the idea (that along with the classes of the instances in the path). Yes, it will try to scan a large space, but that is the nature of this sort of query—it is just expensive (but very powerful).

James

On Mar 26, 2015, at 11:28 AM, Pierre CHANSON <[hidden email]> wrote:

Nice work on the visualizations! (https://vimeo.com/123261640)

Thank you ! These are ideas with the help of Dale. We (Roassal) would like to do some useful object visualizations for Gemstone, profiling code in the repository and potentially the repository state itself. This visualizations can work on a TODE-client-pharo-image with Roassal package. (Or on any Pharo image including TPZ-talk package and script and good configuration... but this is just a try for now) :)

Thanks a lot for the good explanations, it is really clear now .

There is still one thing I wonder:
The common use of that method suppose that you already have an idea of what is the delimiting collection of objects that could have a reference (the roots) on your objects you would like to kill.
So, supposing that you know that this or this objects should be garbage collected, how do you know what could be the delimiting objects that have a reference on it? In that case are you not supposed to try the scan on a very large spectrum  ?

Thanks again a lot,

Pierre 

2015-03-26 12:36 GMT-03:00 James Foster <[hidden email]>:

Hi Pierre,

Nice work on the visualizations! In GemStone (as with any Smalltalk), one is sometimes faced with the question, “Why is my image (or repository) growing?” If you are intentionally adding data to a record, then that’s fine, but if you are expecting a “steady-state” then growth would be unexpected. For example, if your application design is to remove tickets when they are closed, then you would expect a (fairly) stable system.

Given the object graph nature of Smalltalk, things will be garbage-collected if they are not reachable from a persistent root (in Pharo it is the SmalltalkImage singleton or the SystemDictionary in globals; in GemStone it is AllUsers). Thus, the question, “Why is my image/repository growing?” has a simple answer: “Because there are objects that aren’t being garbage-collected!” The question, “Why aren’t these objects being garbage-collected?” also has a simple answer: “Because they are reachable from a persistent root!” 

This suggests the question, “What are the path(s) to some objects that I think should not be referenced?” That is, I’ve removed them from my master collection (say, OpenTickets), but they still exist in the image/repository. Typically what we find is that in an effort to optimize some lookup, we keep a cache of references. For example, I want to know which tickets an employee is handling. Instead of iterating over all the tickets (which could take more time), I have a collection of assigned tickets in the employee object. If I remove an object from the master collection, it doesn’t automatically get removed from the employee’s active list. 

By running the method #’findAllReferencePathsToObjects:limitObjArray:printToLog:’, you find that a ticket is held by a collection that is held by an employee. This brings you to the realization that you forgot to remove tickets from the employee’s active list when they are closed. That is a typical use of this method.

James

On Mar 26, 2015, at 6:10 AM, Pierre CHANSON <[hidden email]> wrote:

Hi James,

ok I understand know that using this method you are supposed to have a bunch of objects that you know you don't need to exceed in the scan.

I have this very quick video to explain what I am doing, the scan method is used arround 2:30 https://vimeo.com/123261640

So I was more in going from an object to another without limit, but I was not well aware of the real uses.

Would you have some example of common uses with this method ?

Thanks :)

Pierre

2015-03-25 22:23 GMT-03:00 James Foster <[hidden email]>:

I’m not sure I understand the question. The first argument, the object list, is the collection of objects for which to search. The second argument, the limit collection, tells the system to stop searching backwards when it reaches one of these objects. Thus, you will have an answer of paths from each of the objects in the first collection to each of the objects in the second collection.

Finding all references to every object is an unusual request. What are you trying to accomplish? Usually you have a handful of objects and are wondering, “Why isn’t this getting garbage collected?” This method helps with that. 

James

On Mar 25, 2015, at 6:14 PM, Pierre CHANSON via GemStone-Smalltalk <[hidden email]> wrote:

Hi everyone,

I am working with the interesting method:

Repository>>findAllReferencePathsToObjects:limitObjArray:printToLog:

and I actually have troubles to define the limitObjArray, how can I increase it from the default one ? for example on every Objects of my gemstone ?

Thank you,

Pierre

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk