"Andrew Groth" <firstname.lastname@example.org> wrote in message news:email@example.com... >> No. >> >> When a non-handle object is no longer accessible, it and all its >> properties are cleared from memory just like normal variables when they >> go out of scope (like when the function whose workspace they are in >> exits.) If that non-handle object contains another object in one of its >> properties, then if that other object is a non-handle object it too will >> be cleared from memory; if it is a handle object, its delete method (if >> any) will be called, then it will be cleared from memory. Thus in >> neither of those situations do you, the user, need to do anything >> special. >> >> When a handle object is no longer accessible, the same procedure as I >> described above happens, except that its delete method is called before >> it is cleared from memory. The reason the text above calls out >> non-handle objects, I believe, is because they operate somewhat >> differently than users may expect based on their experience with other >> object-oriented languages (in that they don't have destructors.) >> >> -- >> Steve Lord >> firstname.lastname@example.org > > Hi Steve, > One of the things I'm experiencing with my handle objects is that, when > deleted, they are no longer in the workspace, but the memory isn't freed > (or not all of it is). If I run "memory" before and after I delete the > object and the net difference is smaller than the difference when > creating. I am working on a continuously running deployed application that > needs to run for long periods of time. I'm experiencing incremental memory > increases with each callback run, can't figure out the source of the > increases, and have not found a way to release the memory without closing > and reopening the application.
It's going to be difficult to diagnose this in the abstract. One potential avenue for investigation would be to check that that nothing (like an anonymous function handle or another handle object) still "knows about" the handle object and is keeping it alive, but there are others.
The easiest way to determine what's going on will probably be for you to send a sample (small) object and a small program with which you can reproduce this behavior to Technical Support and work with them to determine what's causing this memory retention. Once you've done so, perhaps you could return to this thread and summarize what you and Technical Support have learned.