.NET reference management

[m3chtroid]

I inherited a .NET control library that didn't close any of its object references, so I'm currently going through and adding that. However, I'm finding it really hard to tell if closing them as arrays of .NET objects is working or not, as the memory difference is negligible.  Will this technique for a vi properly close all its .net references?

[cbutcher]

The effect will be the same as if you closed them all separately, possibly with a Flat Sequence Structure sequencing them in the same order as your array.

Whether this is "properly" depends on if they're valid references when their closed, but if not it's presumably because they were already lost by closing something else earlier (and so an invalid reference is passed to Close Ref).

You might take a look at the Desktop Execution Trace Toolkit if you're particularly worried about dangling references.

[Kyle97330 · Accepted solution]

It's hard to tell without context but it looks like this is just a method of some kind that has an accessor it's using as a property node to get the DataGridView .NET wire reference.

As such, that probably means the DataGridView reference it gets at the beginning is NOT done being used, and shouldn't be closed here.  It could be closed elsewhere if there's a definite time in your program when you're done with the object, or at the end of your program execution (manually or just let it automatically unload).  The world won't end if every light-blue wire doesn't have a close reference on it at the end of each and every VI...

[wiebe@CARYA]

---

@m3chtroid wrote:

However, I'm finding it really hard to tell if closing them as arrays of .NET objects is working or not, as the memory difference is negligible.  

---

You're not closing .NET objects. You are closing references to .NET objects!

Those references are small pieces of memory. The object an open reference keeps alive can be huge.

You're changing an object that lives inside the DataGridView. So closing the references to that object will make it leave memory once the DataGridView is done with it. If you don't close the references, it might linger on, forever (it might not be forever if DGV destroys the objects).

So you should close the references the way you are doing it. You can probably close each reference right after you're done with each one of them. No need to collect and postpone the close until you're done with all of them. But don't expect memory to be released until the DGV is releasing the object.

It's only a problematic memory leak if each iteration costs memory that's never released. That should be your test. Put it in a loop (continuous run is not the same), and see if memory keeps growing. If not, you're OK, if it does, keep on closing things.

Of course posting a VI (not an image of it) that demonstrates the potential problem helps us help you.

[m3chtroid]

---

wiebe@CARYA wrote:

---

---

You're not closing .NET objects. You are closing references to .NET objects!

Those references are small pieces of memory. The object an open reference keeps alive can be huge.

---

I understand I'm closing references, but instead of closing references to DataGridViews, Rectangles and the like, I'm first casting them to an array of .NET mscorlib.Objects.  What I meant there was that I was unsure if this cast (so they'd all fit into an array of a single type) before passing them to the close reference function would still allow them to close correctly.  

And you're right in that the objects could be closed sooner, but I found this easier to wire and keep track of, just out of personal preference.

[rolfk]

You definitely should NOT close the DGV refnum itself except in the Destroy method to your DGV class implementation. As you stored that refnum in the class private data it is “owned” by this class object and its life time should be managed in accordance with the object lifetime rather than being closed in (any) arbitrary method of that object, The other refnums should be all closed if you don’t store them in the private data (to cache them for performance reason)!

Basic rule: A refnum is either stored somewhere (owned by that entity) and should be closed when that entity is closed/destroyed/freed, or it should be closed as soon as it is not used anymore.

A single unclosed refnum uses up a few 10 of bytes (and the memory of the object it references). While that is not a catastrophe if it happens a few times in the lifetime of an application, it can get seriously troublesome if such a VI is called over and over again in a loop or something!