Transient leaks

[ConvertFromOldNGs]

by Robert >> Mon, 4 Jul 2005 21:16:47 GMT

3. If a methodTransient is assigned to a property <snip> is the property automatically set to null when the method is exited?

AGC only cleans up un-referenced objects, so surely this would require an explicit delete?

transparent & backward compatible ...

Definitely the ideal, but is there a workable implementation? Would this involve new language semantics? What knowledge of the code would someone supporting a heritage system require, e.g. to be sure that <oid>.asOid isn't used anywhere?

[ConvertFromOldNGs]

by Patwos >> Tue, 5 Jul 2005 1:13:17 GMT

"What knowledge of the code would someone supporting a heritage system require, e.g. to be sure that <oid>.asOid isn't used anywhere?"

This one is easy to check in JADE. Simply select the method and do a references to see if it is being used anywhere.

I do like the idea that any form of AGC that was introduced would be such that it can be turned on and work without any change to the language semantics so that it automatically applies to existing systems/code. For legacy systems where this causes a problem due to some dodgy coding practices to get at unreferenced transients, it would be nice to think that this would be found during your regression testing process prior to turning on such an option in production.

To help with tracking down transient leaks, it would be nice to have an ini file option for an AGC facility to log information to file about any transients that are being deleted by AGC. The current technique of checking for undeleted transients on application shutdown will no longer find the rogue transients if they have already been deleted by AGC.

Even with an AGC facility, this does not remove the responsibility from the developer to be conscientious and diligent with their transient deleting but it would be nice to know that any transient leaks that happen to slip through will be less likely to cause any downstream issues that affect system availability.

Pat.

[ConvertFromOldNGs]

by Robert >> Tue, 5 Jul 2005 4:30:35 GMT

This one is easy to check in JADE. Simply select the method and do a references to see if it is being used anywhere.

Oh, and better check references to sendMsg while you're at it ...

[ConvertFromOldNGs]

by Patwos >> Tue, 5 Jul 2005 5:12:36 GMT

"Oh, and better check references to sendMsg while you're at it ..."

If you know a way to utilise sendMsg to invoke a primitive method, such as String::asOid, then it sounds like you have the answer to Torrie's question over on the jade_tech_general Newsgroup...

If not, then using the references option in JADE should in theory show all places where String::asOid is being used.

Pat.

[ConvertFromOldNGs]

by Patwos >> Fri, 8 Jul 2005 1:35:38 GMT

Further to this, for Jade 6 systems you can help ensure your usage of methods via sendMsg are also found via the references option by using the new double colon notation to refer to the method rather than a String literal. Take the following mocked up JadeScript. It will execute the SomeClass::someMethod method twice. The first example is how developers commonly coded it pre Jade 6. The second example shows how you can achieve it in a way that will be cross-referenced. You also have the advantage that any rename of SomeClass::someMethod will automatically update and referencing the code, thereby reducing potential for runtime only detection of the problem via a 1010 exception. A similar approach can be used for specifying the callBack methods for the various asynchronous TcpIp methods.

Code: Select all

vars someClass : SomeClass ; begin create someClass transient ; // String literal, will not be included in references to someMethod someClass.sendMsg( "someMethod" ); // Use new double colon reference to the method so that it will // be found when doing a references to someMethod someClass.sendMsg( SomeClass::someMethod.name ); epilog delete someClass ; end;

Hope that helps,
Pat.

[ConvertFromOldNGs]

by Patwos >> Fri, 8 Jul 2005 1:38:54 GMT

<snip> "You also have the advantage that any rename of SomeClass::someMethod will automatically update and referencing the code," <snip>

..... that was meant to say "update and compile the referencing method"....

[ConvertFromOldNGs]

by cnwjhp1 >> Tue, 5 Jul 2005 5:17:05 GMT

3. If a methodTransient is assigned to a property <snip> is the property automatically set to null when the method is exited?

AGC only cleans up un-referenced objects, so surely this would require an explicit delete?

If method transients are deleted when the method finishes, shouldn't transient class references be deleted when the referring object is?

transparent & backward compatible ...

Definitely the ideal, but is there a workable implementation? Would this involve new language semantics? What knowledge of the code would someone supporting a heritage system require, e.g. to be sure that <oid>.asOid isn't used anywhere?

I would have thought the .ini file option would take care of this. As for AutomaticCacheCoherency, I imagine a lot of people would be able to simply turn it on and use it. And then remove thousands of lines of epilog.

[ConvertFromOldNGs]

by Brendan >> Tue, 5 Jul 2005 14:17:40 GMT

Looks like I didn't make it clear what I was getting at. Consider "create xxx methodTransient;".
If xxx is a local variable then when the method exits, the transient object pointed at by xxx is deleted by the system. No problem.

However, if xxx is a property of self, say, there are three possible implementations when the method exits
1. delete the transient pointed at by xxx as before, leaving the value of xxx as it is
2. don't delete the transient because it is being referenced
3. delete the transient and set the property xxx to null (as would happen if delete xxx was in the epilog).

The problem with 1 is that we now have a reference pointing at a deleted object. Not good. Both 2 and 3 are workable but my point was that the decision not to delete in this case but to delete in other situations is starting to look more like a full blown AGC solution anyway, so why bother with the compromise of methodTransient. To keep track of enough information to set xxx to null would be even more difficult. If this kind of work needs to be done anyway, transparent and backward compatible approach seems a much better way to go.

Is there a workable implementation? Yes I'm sure there is. In fact, the basic ingredients have been in JADE as long as I can remember (the hidden _persistentImpRefs and _transientImpRefs properties on Object). Since it would be transparent, no new language semantics would be required and heritage code would work immediately. <oidString>.asOid is irrelevant since the AGC would neither know nor care how a particular oid has been derived. It operates at the jom level, not the interpreter level. It "merely" needs to keep track of how many things are currently pointing at a given process transient and, if none, delete it.

Brendan

[ConvertFromOldNGs]

by cnwjhp1 >> Wed, 6 Jul 2005 2:07:48 GMT

What difference does it make if the transient is referenced or not? Persistents are not exempt from being deleted just because they are referenced.

Why not simply have the interpreter add an item to its list of "transients to be deleted at the end of the epilog" when the transient is a method variable, and the list of "transients to be deleted when the object is deleted" for class attributes?

With an .ini file option to control this automatic delete, is the methodTransient option even required? You can always make it sharedTransient if you don't want it to be auto-deleted, or turn off the .ini file option.

Cheers,
John P

[ConvertFromOldNGs]

by Alan >> Tue, 12 Jul 2005 9:10:16 GMT

Cleaning up locally created references automatically would not be appropriate. I have at times created a singleton Connection sub-class object (as a local variable so that relevant attributes can be set) whose function is to sit in the background listening and processing. I do not assign this as a reference to any other object – cleanup is performed in the finalize method by accessing the singleton again then deleting it. There are implications with creating it as shared transient (transaction state being one).
With the methodTransient the control / intent of the created object remains under the control of the developer, where I believe it should be. I think most other automated solutions are going to have cases where we wished there was an exception to the rule.