Comments by adamvanner (Top 6 by date)

adamvanner 17-Jan-11 12:35pm View

oh and by the way, irony of all ironies... and youre in some way entitled to go into smug mode here.. the node I deleted did eventually get collected,.. but it seems to take between 5 and 15 minutes!! Ive never even realised objects would linger that long. maybe the extra 4 Gb of memory makes the GC less quick off the mark?

Im glad that shows avRef is working properly, but I'm still going to finish off the scene traversal function as it could well come in handy. Will post as an article once done.

adamvanner 16-Jan-11 23:56pm View

To give you a full idea of the project and the effect that is occurring:

The program Im working on has a script interface as well as a Node/ OpenGL 3D view based GUI. Im testing fail conditions within scripts. So the user enters a script which encounters an exception some way through. The script has run some way through and I must undo the parts of the script which it ran successfully, and flush the undo queue.

The complexities stem from the fact that when an object is created, it informs subscribers to global events (such as editors and 3Dviews) that they should show it/draw it etc. Now some time later in the script, an exception occurs and a second event must be called to say the same object must be deleted. All registered editors, the undo queue, and the scene graph show the object to be successfully removed, but even if I wait 10 minutes, when I check the weak reference, its target still points to the lingering, deleted and disposed object, so something is still pointing to it. If I wanted to, I could ignore it. It makes apparently no difference... but it should have been collected so something isnt being used the way it should be and so all I want to be able to establish is what reference is keeping it lingering.. I dont want to GC the object, but its important for me to find out why it isnt being GC'd. Make more sense now?
Again, I'd just point you back to the title of my question!

unless youve heard of an unreferenced object not being collected after 10 minutes? Could that happen?

adamvanner 16-Jan-11 23:44pm View

Again, perhaps Im being sloppy and youre picking up, rightly, on my semantics..

the point I was making about the spotlight is that it is no longer needed as soon as that snippet leaves scope.. whether GC happens immediately or later is of no concern,.. it should happen because the object isnt needed.

Just so were on the same page and you know I know about GC... ;)

GC occurs when there are no more references to a heap object. When? could be 1000's of times a second, could be much later. More often than not we dont know or care (unless dealing with native resources) The GC thread checks for unreferenced heap objects (not using old VB style ref counting which encounters lost "pairs" of self refed objects) When using "using" with an IDisposable object, the dispose method is called at the end of the scope. The remaining memory may be collected, or as far as I understand it, be reused if called frequently. As you so rightly say, we should not know or care,.. thats the point of GC, to take away the owness of memory management from the programmer... and .net does a very good job of it too!

Ive been coding in C# for 6 years now, so Im really genuinely not confused by GC in any way!

The point is not that Ive lost a ref to an object (as you say, we dont care when that happens). The point is that the WeakReference has shown me that there is still at least one reference in my code, somewhere. Possibly in the containers, (although since the ones ive checked are verified null, the rest should all work as they are all treated the same)... but thats why Im writing this code.. to check!! thats all!

adamvanner 16-Jan-11 23:24pm View

lol sorry perhaps Im making this more confusing than it needs to be! I mentioned Dispose() there ONLY to say that this isnt to do with freeing resources etc!
Lets say the user has selected a light and deleted it. I disconnect everything, call the Dispose() (reason: developers can write plugins to extend these types, so feasibly there could be some native data which needs to be freed, for example, the code uses OpenGL so its critical that clients have the opportunity to free unmanaged resources in a strict order.

Basically after the object is deleted, it should be disconnected from the world. Think of this as a "side effect of the system" more than goal of the system. This genuinely ISNT about memory management, moreover reference management.

adamvanner 16-Jan-11 22:55pm View

yes, thanks.. to be fair I only ran this once on a very simple case knowing full well that it wont work when searching through most commonly field / property types such as arrays & collections, generics, indexers etc. The combinations start to become pretty horrendous! Still Im working through them, but it will definitely take a fair dev time to enable it to be able to graph every facet of a program! Maybe a week of PT coding :/

adamvanner 16-Jan-11 22:14pm View

Im aware of GC and its implications and that of course there is no explicit delete. The project Im working on is large- last count over 400 .cs files, so its very important that if anything stands out as being wrong (such as uncollected objects which have no reason not to be collected since they should be unreferenced), I know precisely what is causing the effect, even if the user is unaware of any problem. I am explicitly calling Dispose() for these objects as they are definitely not needed, so its not an issue of memory, but of predictable behaviours.

The system uses lazy evaluation and a DAG graph, so having hanging nodes lingering has the possibility of producing problems that are very difficult to trace, hence my care!

To answer to your question, what will I do with the references? Change them to use our referencing system (avRef)! avRef is such that any node maintains a collection of all references and lists to that node. All persistent references to the node need to happen through a container. Clients of the container can listen for events such as the node is renamed or deleted. Its a straightforward system that makes everything very safe, testable and traceable.

e.g.
avLight spotLight = new avLight();

avRef<avLight> defaultLight = new avRef<avLight>();
defaultLight.Target = spotLight;

avRefList<avLight> lights = new avRefList<avLight>();
lights.add(spotlight);

// the following results in the avRef's Target member being set to null and spotlight being removed from the lights list.
spotLight.Delete();

Make sense now? So as soon we leave scope that "spotlight" is defined in, collection should occur. It does. Normally! I want to know what is maintaining a reference.. in my code nothing should!