Transient cleanup and DictIterator

[ConvertFromOldNGs]

by CarlRanson >> Thu, 7 Nov 2002 3:43:54 GMT

I agree that its a terribly difficult problem to work out which transients can be thrown away.
Im no expert, but i believe in the cases that it can be done it amounts to a graph connectivity problem, which is np-hard. But, as you point out, all transients are accessable via Jade which kills that plan dead in the water.

What about a simpler methodology whereby a class could be nominated as "transient cleanable". I would imagine the semantics to be that the epilog of any method that makes a transient instance of that class would automatically delete the instances made.

I guess it would be a new creation modifier as well, eg.

create iter transient cleanable;

that way it fits into the existing architecture of Persistant/transient on class definition or creation.

It would be pretty easy to implement i think, Jade would just have to keep an objectarray of objects created as "transient cleanable" for each method, and purge it in the epilog.

Any advances on this idea?
CR

[ConvertFromOldNGs]

by cdshearer >> Thu, 7 Nov 2002 9:24:34 GMT

Hi Carl

I think this is a reasonable idea, but I think there'd be too many exceptions to it for it to be a total solution. I'd much rather see the plant implement your suggestion of being about to connect the transient instance with the method that created it, then diagnosing transient leaks would be a breeze. But it's certainly the sort of thing that you'd want to be able to turn off in production, safe in the knowledge that all your testing during development had located all transient leaks... (ah, there goes another pig flying by!)

I think automatic garbage collection is really the answer though. When you have this feature, it's amazing the difference it makes to writing code. You can use objects much more freely. For example, you know that it's safe for a method to create and instance and return it, knowing that once it's no longer referenced, it will be a candidate for garbage collection. Similarly, you can create objects and pass them into methods without having to worry about deleting them later. Of course, that sort of thing is much more convenient with parameterised constructors! (But don't get me going!)

Craig

[ConvertFromOldNGs]

by allistar >> Fri, 8 Nov 2002 1:08:22 GMT

Hi there,
We have a rule with our development that a transient object must
always be deleted by the method that created it. As you say this can
be missed, we have a "find transients" script that runs when we are in "test mode" that identifies unexpected leaks.

Part of me disagrees with the notion of garbage collection as it promotes sloppy coding (in my opinion if you create an object then you should be responsible for deleting it - this also means you have more control over the performance and memory usage of your application as
you can decide exactly when you delete it).

Allistar.

[ConvertFromOldNGs]

by cdshearer >> Fri, 8 Nov 2002 3:38:12 GMT

I also agree with the rule that the method that creates the transient should delete it, but only if possible. There are more complex situations where that isn't possible, and it also means that it restricts you from writing methods that create and return new collections or other objects (if you enforce the rule).

I think your objection to garbage collection on efficiency grounds is a bit of an old world view. Would you frown on high-level languages too because they don't allow the developer to control what CPU registers are used? I think there are enough implementations of automatic garbage collection now to prove that it's a workable concept, usable in real world applications.

Craig

[ConvertFromOldNGs]

by JensRichnow >> Fri, 8 Nov 2002 7:22:03 GMT

I agree with Craig in that gc has its place. Yes, I guess most of us follow the rule of thumb that the methods which create the transient should clean it up as well. However, as pointed out, it is not always possible. For certain tasks I manage a transient 'pool' for transient re-use and subsequent gc.

In my mind gc does not encourage sloppy coding but provides a the re-assurance for those odd cases where management of transients would impose a rather complicated coding overhead I'm not particularly keen in.

[ConvertFromOldNGs]

by hml >> Fri, 8 Nov 2002 9:31:06 GMT

From what I hear Jade are looking at more options for object lifetimes eg persistent transients etc. Several people have said that they like to delete transients in the method that created them. Would another object life time of methodTransient be a good idea to allow transients to be automatically cleaned up at the end of the method? (Jade could wait internally for a quiet point to clean up but I imagine some people would want it to happen at the end of the method call so perhaps an Ini file setting?)

Perhaps another option would allow a exclusive reference to a single object. Jade will create an instance of a exclusive collection the first time it is referenced and clean it up when the object is deleted. If this was extended to single object references it would also allow transients to be automatically cleaned up when their logical parent was deleted. (maybe the parent child inverse relationship handles this case already?)

In all other cases the developers would be responsible for cleanup but I imagine these would be far fewer than the two cases above.

[ConvertFromOldNGs]

by johnmunro >> Fri, 8 Nov 2002 15:43:44 GMT

Is there any reason why Jade can't use COM style reference counting?

Every time a new reference to an object is created, its reference count is incremented, and every time a reference is removed, the reference count is decremented. When the reference count hits zero, the object is garbage collected...

John Munro

---
Synergist Limited - Home of FileVisionT
The Bioscience Innovation Centre
Cowley Road, Cambridge, UK
CB4 0DS

Telephone: +44 (0) 1223 478200
Fax: +44 (0) 1223 477969
Email: john.munro@filevision.com
Web: http://www.filevision.com

The contents of this communication are confidential and are only intended to be read by the addressee. We apologize if you receive this communication in error and ask that you contact Synergist Limited immediately to arrange for its return. The use of any information contained in this communication by an unauthorized person is strictly prohibited. Synergist Limited cannot accept responsibility for the accuracy or completeness of this communication as it is being transmitted over a public network. If you suspect this message may have been intercepted or amended, please inform Synergist Limited.

[ConvertFromOldNGs]

by CarlRanson >> Sun, 10 Nov 2002 22:23:13 GMT

This is essentially what I was getting at earlier in this thread.

the current Transients have a lifetime of the process or node (if sharedTransient). methodTransient has the same lifetime as the current method.

The more I think about this one, the more it seems like a good idea. I think i will put in a NFS for this.
CR

[ConvertFromOldNGs]

by allistar >> Mon, 11 Nov 2002 0:32:02 GMT

I agree that often it's not as simple as deleting the transients in
the same method that creates them (especially for large processes that are entirely transient based and quite heavily subclassed. In that
case I would delete just the root transient object and it becomes responsible for deleting any child objects).

I don't object to garbage collection because of efficiency per se, I
just see it as a fix to a problem that shouldn't exist. I.e. there shouldn't be any leaking transients, and if there are the correct way
to address this issue would be to not leak them in the first place, rather than have some complicated process running around and cleaning
up after you.

It wouldn't be too tricky to implement a rudimentary gc system in
Jade, as long as all transients have inverses. If all of an objects references are null (or collection are empty) then it mustn't be referenced anymore and can safely be deleted. You could run the gc process at a quiet point.

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

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

[ConvertFromOldNGs]

by cdshearer >> Mon, 11 Nov 2002 2:40:03 GMT

The whole point about garbage collection is that cleanup is done for you completely. There is no real concept of a leak as such, as generally, there is no delete instruction in the language. The GC takes over managing objects for you, and deletes objects once they are no longer referenced. So the only way you can have a "leak" is by retaining a reference to an object you no longer intend to use.

I think, though, that in the case of JADE, the paradigm is strongly focused around the concept of a database, and this includes transient objects too. Every object in JADE has an object ID, even transients, and so the overhead in managing these is much higher than in other languages. (Have you ever considered the overhead of creating a persistent object in JADE? There is, of necessity, a trip to the server, so that a unique OID can be allocated. This allocation of the OID occurs in a separate "transaction" - as if you abort the transaction, you lose these OIDs. The code to allocate OIDs and ensure no duplicates must be interesting to say the least... One could make an argument that by exposing Object IDs to the developer, JADE limits performance. If OIDs were hidden and could never be displayed or used, then various efficiencies could be realised, such as not having to allocate OIDs for objects until the transaction was committed at the server.) Of course this is all academic... this will never change!

However, since JADE does have to manage transients carefully, you would think that garbage collection would be a much simpler task than in other environments.

Craig