> Loading and holding the references at startup is the solution I
> suggested to the developer who ran into this, for some reason I've
> never discovered this limitation myself. So it's not a big problem,
> but one (too) easily overlooked.
>
True, this limitation has been there since LV5. It is a temporary
ordering of things that resolves itself as soon as the modal VI goes
away, so it very rarely affects an application.
> We do however more and more develop application where there are
> parallell independent (should be that is) operations going on all the
> time, and this seems to introduce problems that are not always what
> one would expect. The memory leak described in the following is one
> example:
>
This looks a bit like a sneaky way of asking me to look at your "memory
leak" problem. I modified it a bit, changed the delay to 20ms instead
of 50, and made the button be a switch instead of latched, so I could
just let it clone all by itself. Running it in a normal version of LV,
I let it create and then I'd delete. All total, I created and destroyed
about 300 VIs, and the memory on my LV for OSX would go up a few megs,
then back down, then back up bit. I then tried it with a debug version
where I can look at the amount of memory that LV thinks it has allocated
at any point in time.
My quick diagnosis? It isn't a leak, but the extra memory usage is due
to fragmentation. Basically this stems from the fact that loading a VI
means bringing quite a bit of stuff into memory. To do this LV asks the
OS for some allocations. When tearing down the VI, LV frees the
allocations, if it didn't, this would cause a leak.
But, just because allocations are freed doesn't mean the system will
show them as free to give to another app. Here is why. If a program
asks for one byte, the OS will add one page of memory to the app -- that
is 4096 bytes. If the app asks for another byte, the OS doesn't have to
do much, it returns one of the 4095 reserved bytes that belong to the
app. After the 4096 bytes are used, the OS will give the app another
page for 9192 total. Interestingly, if the app starts deleting bytes,
the OS will only be able to take back a page and make it available for
other apps when no allocations are on that page. So leaving the first
byte allocated and say the 5000th byte allocated are enough for those
two bytes of allocation to use up 9192 bytes of memory.
This effect is caused by fragmentation, and it is there largely because
memory is cheap, so the OSes don't do any compaction. 4096 bytes on
even a 64Mb machine is a tiny drop in the bucket, so the OS trades space
for time and wastes memory to increase performance.
So, this isn't a guarantee that this isn't a leak. You did the right
thing in reporting it, and another person in R&D will spend more time to
verify that there isn't a leak, especially in the new AutoClose Refnum
feature. But my quick diagnosis is that as the app loads up a new VI,
some of its lists and arrays grow and are moved to some of the new pages
leaving behind holes. When the VI leaves memory, some of the pages
can't be freed because even though the arrays and lists have shrunk
back, they stay on the new pages. After a few of these chaotic
operations take place, an equilibrium is reached and the app will stop
growing. The pattern it takes, and the amount it grows is highly
dependent on the OS and the heap manager in use. So, on OSX mine may
only grew 3M, whereas one version of windows may grow 4M and another
10M. At any point, it is largely out of LV's control and isn't a true leak.
I hope this helps.
Greg McKaskle
