[GemStone-Smalltalk] Scanning objects

[James Foster via GemStone-Smalltalk]

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 <chans.pierre at gmail.com> 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 <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 <james.foster at gemtalksystems.com <mailto:james.foster at gemtalksystems.com>>:
> 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 <gemstone-smalltalk at lists.gemtalksystems.com <mailto:gemstone-smalltalk at lists.gemtalksystems.com>> 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
>> GemStone-Smalltalk at lists.gemtalksystems.com <mailto:GemStone-Smalltalk at lists.gemtalksystems.com>
>> http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk <http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20150326/84e431a7/attachment.html>