global declaration is in stack or in heap?

wroom · 11-08-2015, 07:25 AM

Quote:

Originally Posted by wroom

Use global static variables to preserve data between function invocations. Not the function local static variables.

Quote:

Originally Posted by psionl0

Better still, any variables that need to be conserved between function invocations should be stored by the calling function and a pointer passed to those functions that need it.

Good clarification. The caller should explicitly reference global data to the called function through pointers.
Referencing global variables by name in a function is most often "asking for trouble". But in some cases it is still needed.

Quote:

Originally Posted by wroom

For realtime performance, and also for reliable execution, the concept of avoiding dynamic allocation is essential. Global and static allocation is enforced, and dynamic allocation kept to an absolute minimum.
Having lots of small functions that allocate large arrays/buffers dynamically, for a short time, either on stack or in paged memory, are detrimental to reliable, predictable realtime performance.

Quote:

Originally Posted by psionl0

I have never heard of this rule of thumb before. Is this because of the way Linux allocates memory? There are many cases where the amount of memory required can not be known beforehand and dynamic allocation is the only way around this. In some languages (like Java), every non-elemental variable has to be dynamically allocated.

Interesting point. I think Linux is very efficient in its handling of memory.
But the rule was for "realtime performance". You know, when certain memory pages are locked into RAM, and certain code and data is locked into CPU cache, or the system is designed totally without both paged memory and dynamic cache.
A desktop or server Linux is not a realtime system. An Anti-lock Brake System in a car is running a realtime system. A system with 100% deterministic response time.

Calling malloc or free invites the running of garbage collection mechanisms that are non-deterministic in execution time.

This makes languages like Java, and some central use cases of C++/Cpp totally useless for realtime applications. (Although useable for non-deterministic background processing in the same system as long as it never interferes with the realtime applications).

psionl0 · 11-08-2015, 08:03 AM

Quote:

Originally Posted by wroom

Calling malloc or free invites the running of garbage collection mechanisms that are non-deterministic in execution time.

It was always my understanding that C/C++ doesn't have garbage collection. That's why you need to free/delete the allocated memory when finished with it. It can lead to heap fragmentation though.

wroom · 11-08-2015, 09:52 AM

Quote:

Originally Posted by psionl0

It was always my understanding that C/C++ doesn't have garbage collection. That's why you need to free/delete the allocated memory when finished with it. It can lead to heap fragmentation though.

If a C/C++ program running on Linux uses malloc a couple of times during it's execution, but does not 'free' that memory, the memory will still be free'd to the system when the program exits.

It is true that C/C++ does not do the same periodic garbage collection as Java does/(has to do).
Bot there is still some garbage collection tasks running at certain points.

It is noteworthy that a malloc will return before all the allocated memory is actually mapped in physical memory.
You can in fact overallocate. As long as you don't use all that memory at once, it will not be mapped until it is really needed. But the system will start looking for unused pages that it can use to map the allocated virtual memory. Throwing out pages that was used for file caching. Linux will not keep that much memory as 'unused'. It will use the physical memory the best it can.

Take a look at this example statistics from 'top':

Code:

top - 15:34:32 up 77 days,  7:59, 20 users,  load average: 0.42, 0.44, 0.40
Tasks: 367 total,   1 running, 364 sleeping,   2 stopped,   0 zombie
%Cpu0  :  1.9 us,  0.3 sy,  0.0 ni, 97.7 id,  0.1 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  : 43.0 us,  2.2 sy,  0.0 ni, 54.4 id,  0.3 wa,  0.0 hi,  0.1 si,  0.0 st
%Cpu2  :  1.7 us,  0.3 sy,  0.0 ni, 97.6 id,  0.4 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  5.2 us,  1.3 sy,  0.0 ni, 93.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:  33013484 total, 32433956 used,   579528 free,   137252 buffers
KiB Swap: 67100664 total,   785936 used, 66314728 free, 29870660 cached

Think about what happens when some program allocates 24 GiB of heap memory on this machine.
There is only 579528 KiB free memory in the system. But it will kick out some of the 29870660 KiB of file cache pages to fulfill the requested allocation. A page at a time.

I think we have wandered off from the OPs question. But it has been an interesting discussion.

psionl0 · 11-10-2015, 11:59 AM

It is true that the OS will perform a number of memory management tasks during program execution. However, these tasks are all transparent to the programmer.

As far as the C/C++ programmer is concerned, once memory has been malloc'd, that memory available at all times until it has been free'd or lost (no pointers point to the malloc'd memory any more). Not only that, but the programmer can expect the address to remain unchanged for the life of that memory. The address could be stored in a pointer and no matter how long the program waits, it will still be the correct address when the memory is finally used.