Memory deallocation bug

[rob.dye]

@EvgenKo423: I don't know all the ins and outs of the SH implementation, but I do know that above a certain size threshold (I thought it was 64KiB) SH will just alloc straight from the Windows API (VirtualAlloc, I think). SH doesn't do any other management of these blocks, so when LV asks SH to free them, SH immediately calls VirtualFree. This reduction in mem footprint should be visible in Process Explorer (or Task Manager). Another complication, though, is that a performance analysis done by our NI Bangalore colleagues found that VirtualFree was quite an expensive operation, so I believe LV's memory manager layer currently keeps a small cache of freed large blocks in order to avoid the VirtualFree penalty when possible. As I said, these things are complicated. This cache was found to be effective in RFmx applications where large waveforms are being constantly allocated, resized, and freed. 

[EvgenKo423]

OK, thanks for your effort.

[dadreamer]

Thanks, Rob! Very well done research with a lot of technical details, as we all here like. 🙂 After reading and re-reading your post and SH related documents and playing with the samples I still have one question. Can we control SH behaviour in any ways or is it up to LabVIEW Memory Manager completely? Say, could I make SH to empty its pools and free all the data cached, thus reclaiming the space occupied? Or it never gives it back to me entirely? Could I disable SH utilization somehow or is it hardcoded to be always on?

I found few private properties to control Memory Manager settings, e.g. Application.Selective Deallocation, Application.Selective Deallocation.EnableForAllVIs, Application.Selective Deallocation.LargeBufferThreshold and Application.NeverShrinkBuffers, but playing around these doesn't help much. I would say, it even worsens the situation in some cases. Currently I see no way to return the occupied memory, thereby LabVIEW can (and will) eat as much memory as it needs for its purposes. So, we have to live with it, don't we?..

upd: I think I found something. In [LabVIEW]\resource folder there are four variants of Memory Manager library:

• mgcore_20_0.dll - no SH, no AT (Allocation Tracker)
• mgcore_AT_20_0.dll - with AT
• mgcore_AT_SH_20_0.dll - with both SH and AT
• mgcore_SH_20_0.dll - with SH

LabVIEW uses SH version by default. If we switch to "no SH, no AT" version by backupping mgcore_SH_20_0.dll and renaming mgcore_20_0.dll to mgcore_SH_20_0.dll, then the memory consumption is somewhat reduced and we get more memory back after RD was called. On default mgcore_SH_20_0.dll I'm getting these values:

• LabVIEW is opened and the example is running - 199 056 KB;
• After the string array was once created (RD is on) - 779 256 KB (the peak value is at ~800 000 KB);
• After the VI is stopped and closed - 491 096 KB.

On mgcore_20_0.dll I'm getting these values:

• LabVIEW is opened and the example is running - 181 980 KB;
• After the string array was once created (RD is on) - 329 764 KB (the peak value is at ~600 000 KB);
• After the VI is stopped and closed - 380 200 KB.

Of course, it all needs more extensive testing. I see however, that "no SH, no AT" version uses less memory for the operations and so it could be prefferable, when the system is fairly RAM limited.

Edited July 19, 2020 by dadreamer
new info

[EvgenKo423]

@dadreamer, nice find!

Apparently these private properties should do exactly what you want: control SH behavior, but they allow to only control the size of large blocks (which shouldn't be the root of this problem) and don't seem to make any difference in my test anyway.
Library replacement, on the other hand, eliminates this problem completely, even for blocks <256 bytes.

Edit: Selective Deallocation is also available as an INI key along with a key "overanxiousMemoryDeallocation" (which doesn't help either).

Edited July 20, 2020 by EvgenKo423

[dadreamer]

On 7/20/2020 at 2:56 PM, EvgenKo423 said:

Apparently these private properties should do exactly what you want

Well, they're obviously not enough to have an absolute control over SH, including memory pools management as per SH API. Unfortunately I don't see any other functions or private nodes exposed, except maybe FreeSmartHeapPool function of mgcore, but that one crashes LV for some reason.

I'm afraid, my find about mgcore's switching is almost useless, because compiled app (i.e. EXE) uses lvrt.dll, which already has mgcore stuff integrated into it, so no way to disable SH in lvrt, as it would require its recompile from the sources. And I never saw any different versions of LVRT except a classic one and a Full Featured one. Honestly, I don't know, why LabVIEW is shipped with 4 variants of mgcore, even if it's using only one of them.

On 7/20/2020 at 2:56 PM, EvgenKo423 said:

key "overanxiousMemoryDeallocation" (which doesn't help either).

Yeah, it doesn't help much, because it's like you have inserted RD block in the end of every VI. In LabVIEW before 7.x there was "Deallocate memory as soon as possible" checkbox in the settings.

Quote

Deallocate memory as soon as possible - Deallocates the memory of every VI after it completes execution. Doing this can improve memory usage in some applications because subVIs deallocate their memory immediately after executing. However, it slows performance because G must allocate and deallocate memory more frequently and in some instances it might lead to excessive memory fragmentation.

This setting was stored in INI as anxiousMemoryDeallocation token. In 7.x they removed the checkbox and likely renamed anxiousMemoryDeallocation token to overanxiousMemoryDeallocation. LabVIEW still tries to read overanxiousMemoryDeallocation on the start, thus it could be used if needed. Not much sense for that though.

By the way, this wiki page should be updated as well.

[Rolf Kalbermatter]

On 7/21/2020 at 12:27 PM, dadreamer said:

By the way, this wiki page should be updated as well.

You can sign up and do it too 😀