LabVIEW
memory management in labview as C language
LabVIEW will do the memory management for you automatically.
To limit memory use, you need to write the code in a way to limit buffer allocations (e.g. array resizing), limiting data duplication, and optimize for inplaceness. Often, the LabVIEW compiler can optimized the code even of you don't write it in the best way. It is very smart!
For some ideas, have a look at our old NI-WEEK presentation.
In summary, you don't have direct acccess to the memory management, but you can write your code in a way to be optimized for e.g. small size or high performance, or sometimes even both.
You seem to be coming from an embedded development word. .map files have long lost any meaningfulness in modern operating systems. Nowadays the created code is fully relocatable (another word used is position independent code (PIC)) and the operating system does not anymore load code into a well known address space but rather does address randomization when loading code modules in order to make it more difficult for rogue code to locate known vulnerabilities to exploit.
LabVIEW did that actually more or less from the start as the compiled binary code of every VI is linked together at VI load time in memory. It wasn't true randomization to begin with but it had pretty much the same effect as even small variations in the compiled code of one of the used VIs would generally change the memory layout of the loaded and linked code considerably.
If you really want to read more about the internal workings of LabVIEW you can read this where a LabVIEW developer explains in more detail about the inner workings from going from a VI diagram, to a so called DFIR directed graph representation of the code where LabVIEW then does all kinds of transforms on that for high level optimization and after that everything gets send to the LLVM compiler to create the actual target code. While the general principle is similar to a C compiler many of the intermediate steps are pretty different and except for the LabVIEW developers themselves there is no real way to get at the intermediate steps of this process.
As to your last question a compiler basically distinguishes between data space and code space also commonly called data segment and code segments on the x86 architecture. The difference is that while data segments are setup to be both readable and writeable code segments are setup to be only readable after they have been initialized.
The reason is obvious. You do not want some rogue code to be able to change your compiled code at runtime to execute something bad. By setting the memory segment in which the code is loaded to be read only, any attempt to modify that code by whomever will cause a protection fault and shutdown your process for good. Data space however needs to be modifiable. The frontpanel can be modified by changing the size, color and values of the controls and the frontpanel itself. If the memory where the frontpanel is loaded would be read only such attempts would shutdown your process.
Basically you need to know that variables are stored in data space while the compiled code (and sometimes constant declared variables) are stored in the code space. And while I'm not sure LabVIEW even can make code segments read only (generally that is an operation only the kernel itself can do during loading of EXE or DLL modules since it involves changing hardware registers in the memory management unit that are protected themselves from being modified by anyone but ring 0 code) it still distinguishes data and code space.
Well reading a bit further on MSDN you can't execute code in memory that is allocated with HeapAlloc() in Windows. To get such memory one must use VirtualAlloc() and that function allows to specify if the allocated memory area should be write protected. So I'm pretty sure LabVIEW loads its compiled code into write protected memory buffers too.
