Are you running this example in a single VI (not in a project)? And is what you shown the entire block diagram?
I think this example is probably a false 'positive' as a result of a race condition. Close Reference doesn't actually release memory, it simply un-pins the reference in the CLR to enable garbage collection when the next collection sweep occurs. A single VI ending execution in this example ends the VI Hierarchy. Ending a VI hierarchy always causes LabVIEW to release references created in that hierarchy and, in the case of .NET, destroying the App Domain that was created to host all the created .NET objects. This probably occurred before the garbage collection thread(s) have executed to release memory for dead objects in the CLR.
I think in this case you end up with this "false" result being indicated but the reality is all that memory is released when the App Domain is destroyed anyway.
Maybe an idea of your original use-case would be helpful to eliminate other problems.
One thing I should mention is that the statement regarding the App Domain is correct when running a single VI as the top level VI outside of a project. As far as I am aware, in a project there is only one App Domain created per platform - so references can be shared between VI hierarchies and one hierarchy ending doesn't destroy the App Domain.
Well, thank you for your prompt answer, it was very helpful.
At first I briefly answer your questions:
Yes, it is a single VI - without project.
Yes, what I had shown was entire block diagram.
First helpful thing was the VI hierarchy, so I have added one unneccessary VI at the end.
Second thing was the standalone VI - without project.
When I have tried to combine these two things, it seems much better.
The third issue, what I haven't mentioned, was array of types, that I replace with simple TypeList, as you can see on image below. Before I have used Build Array and passed it as constructor parameter.
Just for curious people, here is my solution how to store all refs at one place, and at the and their chronological closing. Chronological because the first created reference has the lowest id, and the last created refernce has the highest id.
I use static class with ulong list, which return sorted array:
There is neccessary convert reference to some number, because when you try to store directly objects, LV will create new references for them.
In LV code then just anywhere use calling static invoke node like that:
and at the end of application pick up sorted array and one by one convert to ref and close:
Of course you can use just LV array of numbers as global var, for example. I like static classes in LV, because I can use only invoke and property node to acces them, without storing variables. (Yes I know that data are stored in CLR, instead of LV runtime)
Just a couple of tips:
Thanks for your tips.
You are right, I shouldn't rely on reference number.
Unfortunately, my program isn't short lived, it will be running for weeks and months without restart, and every minute will be creating tens of new references, so there is a need correctly close them and release memory. So I think over, how to that most brightly.
Maybe creating groups with related refs, and use the chronological principe of Add method within each of them. Because when I close parent reference first, descendants can't close after that.
The reason, why I have used OrderBy, is I don't want to care whether I use Add method in correct order. But there is a need to do that somehow smartly, then order them by number, as mentioned above.