Transient cleanup and DictIterator

[ConvertFromOldNGs]

by JensRichnow >> Mon, 4 Nov 2002 8:58:25 GMT

Hi there,

just looking at transient clean up again and noticed that heaps of DictIterator instances are created by the system. This is especially annoying if multiple child apps are managed (created/destroyed) by a master app whereby the number of concurrent child apps can be x (o.k., limited by the Jade pie for each child app and overall system resource). Anyway, I would be interested how others tackled to problem.

P.S.: All iterators created in the code are deleted if redundant.
P.S.S. Hope, I'm not too tired to pose this question. My apologise in this case in advance.

Cheers

Jens

[ConvertFromOldNGs]

by cdshearer >> Tue, 5 Nov 2002 9:37:30 GMT

Hi Jens

I think you must have been a little tired as I couldn't make much sense of your message! But it did prompt me to think about things and do some investigation into a system I'm currently working on.

Here's some stuff I discovered:

1. You have to write your own routine to check for undeleted transients - typically you'd call this from your Application::finalize method. There is some sample code in the FAQ section of the JADE web site.

2. The provided sample code actually only checks for undeleted transients of classes in your schema - it doesn't check for transient instances of classes from other schemas. So, if you happen to have created some RootSchema transients, then these won't be detected by this code. Below, I've put some better code.

3. JADE's own code isn't necessarily squeaky clean. I found that the Schema Inspector leaks transient instances of the ClassColl class. Admittedly, you're unlikely to use this in a production application.

4. Watch out for how you use some of JADE's methods, as some of them are misleadingly documented. For example, the Class::allProperties method is documented as "returns a reference to..." a collection of properties. When in fact it actually creates a transient collection for you, populates it and passes it back. So, you're responsible for putting the returned reference in a variable and deleting it later. If you do the following, you'll leak transients:

foreach property in class.allProperties() do
// Deal with the property
endforeach;

The correct way to code this is:

vars
properties : PropertyColl;
property : Property;begin

properties := class.allProperties();
foreach property in properties do
// Deal with the property
endforeach;
epilog
delete properties;
end;

5. Once you've identified that you have a leak, it can be very difficult to track it down. So, I would suggest that you run the check code frequently, so that if fresh undeleted transients start to appear, it must be in code you've recently written or modified. For a GUI app, it can help to have some way of triggering a dump of the current transient instances, so that you monitor transient instances at strategic places in your app's execution.


Finally, here's the code for detecting undeleted transients across all schemas for a process:

vars
insts : ObjectArray;
obj : Object;begin

create insts transient;
Object.allProcessTransientInstances(insts, 0, true);

foreach obj in insts do
write obj.String;
endforeach;
epilog
delete insts;
end;

Note that the above code will detect some legitimate transient instances. For example, it will detect the Application instance, and also the actual ObjectArray that is being populated, as well as some other transient instances hanging off app. You could modify the above code to filter out these known transients.

The above code does take some time to execute, so you might want to have a way of switching it on and off, otherwise your app takes an extended time to shut down.

Hope this helps...

Craig

[ConvertFromOldNGs]

by allistar >> Tue, 5 Nov 2002 22:06:10 GMT

On Tue, 5 Nov 2002 9:37:30 GMT, craig.shearer@helix.co.nz (cdshearer) wrote:

Can anyone (from Jade perhaps) provide a list of similar methods that also create transients that we are expected to delete? We look at the Jade meta data quite a bit in our systems and would hate to think that
we are leaking these sorts of transients all over the place.

Thanks,
Allistar. ------------------------------------------------------------------
Allistar Melville
Software Developer
Auckland, NEW ZEALAND

Greentree International,
Developer of Greentree Financial Software. ------------------------------------------------------------------

[ConvertFromOldNGs]

by cdshearer >> Wed, 6 Nov 2002 0:43:02 GMT

Off the top of my head, there's Class::allProperties, Class::allPropertiesUpTo, and Schema::allClasses. There may well be others... Fortunately, most methods like this require a collection to be passed in, rather than returning one. So much for consistency!

Wouldn't automatic garbage collection be a good idea!

Craig

[ConvertFromOldNGs]

by CarlRanson >> Wed, 6 Nov 2002 1:00:43 GMT

I would be quite useful if you could get Jade, as an option, to keep track of the methods that created all the transients.

Then when you shut down the program you could get a list of the remaining transients AND where they came from, which would make it simple to track them down.

In theory it would be a fairly simple modification to Jades create and delete methods as well as the addition of a means to access the list of transients.

Would be a useful addition to the debugger. (I have this idea in as an NFS already, but feel free to repeat it to them)
CR

[ConvertFromOldNGs]

by allistar >> Wed, 6 Nov 2002 2:21:46 GMT

On Wed, 6 Nov 2002 1:00:43 GMT, carl.ranson@unify.co.nz (CarlRanson) wrote:

We wanted to do exactly that by reimplementing the "create" and
"delete" constructor/destructor on the Object class and then working
out the current method we are in and storing the information in a collection that could be iterated through when the application
shutdown.

We had all of the code working fine BUT you can't add the "create" and "delete" methods to the Object class. You can for any other class
though (and if we had all of our classes subclassed from a common (non-Object) class we could have easily tracked our leaky transients).

Allowing us to add those two methods to the Object class would be a
big step in easily diagnosing leaking transients.

Allistar.

[ConvertFromOldNGs]

by barryg >> Wed, 6 Nov 2002 18:52:13 GMT

Adding the obj.creationTime to the dump of transient objects helped us clean up the bulk of our transient issues.
Matching the timestamps against the application logs highlighted our main offenders.

Barry.

[ConvertFromOldNGs]

by JensRichnow >> Thu, 7 Nov 2002 3:02:47 GMT

Yes automatic garbage collection would be marvellous!

It is a much better approach then checking the transient leak at the point of shutting down of the app! Most transients accumulate during the run-time and choke the system, especially those transients created via the various copy and clone methods. Periodically cleaning the transient garbage would be a much better approach. And to a certain extend I'm able to do that. But as you can tell by my posting I cannot fetch all transients.

[ConvertFromOldNGs]

by allistar >> Thu, 7 Nov 2002 3:10:34 GMT

On Thu, 7 Nov 2002 3:02:47 GMT, jrichnow@maketxt.com (JensRichnow)
wrote:

Yes automatic garbage collection would be marvellous!

It is a much better approach then checking the transient leak at the point of shutting down of the app! Most transients accumulate during the run-time and choke the system, especially those transients created via the various copy and clone methods. Periodically cleaning the transient garbage would be a much better approach. And to a certain extend I'm able to do that. But as you can tell by my posting I cannot fetch all transients.

How do you know whether a transient object is being used or not? You could write some horrible code that gets the first instance of a transient object and uses that for something, and you wouldn't want
the garbage collector to delete it. How would it know? (Of course, you shouldn't be writing horrible code like that, but the point is that
you can).

Allistar.

------------------------------------------------------------------
Allistar Melville
Software Developer
Auckland, NEW ZEALAND

Greentree International,
Developer of Greentree Financial Software. ------------------------------------------------------------------

[ConvertFromOldNGs]

by cdshearer >> Thu, 7 Nov 2002 3:43:06 GMT

What I was meaning by automatic garbage collection would have to be built into JADE at the kernel level, just like it is in Smalltalk, Java and .NET and probably other languages too.

As we've all experienced, it's very easy to leak transients, even when you're careful about putting in epilogs in methods to delete transients where you create them. It's very easy to slip up.

Craig