C++ Some Stack questions

Question

Let me start by saying that I have read this tutorial and have read this question. My questions are:

1. How big can the stack get ? Is it processor/architecture/compiler dependent ?

2. Is there a way to know exactly how much memory is available to my function/class stack and how much is currently being used in order to avoid overflows ?

3. Using modern compilers (say gcc 4.5) on a modern computer (say 6 GB ram), do I need to worry for stack overflows or is it a thing of the past ?

4. Is the actual stack memory physically on RAM or on CPU cache(s) ?

5. How much faster is stack memory access and read compared to heap access and read ? I realize that times are PC specific, so a ratio is enough.

6. I've read that it is not advisable to allocate big vars/objects on the stack. How much is too big ? This question here is given an answer of 1MB for a thread in win32. How about a thread in Linux amd64 ?

I apologize if those questions have been asked and answered already, any link is welcome !

Answer 1

1. Yes, the limit on the stack size varies, but if you care you're probably doing something wrong.
2. Generally no you can't get information about how much memory is available to your program. Even if you could obtain such information, it would usually be stale before you could use it.
3. If you share access to data across threads, then yes you normally need to serialize access unless they're strictly read-only.
4. You can pass the address of a stack-allocated object to another thread, in which case you (again) have to serialize unless the access is strictly read-only.
5. You can certainly overflow the stack even on a modern machine with lots of memory. The stack is often limited to only a fairly small fraction of overall memory (e.g., 4 MB).
6. The stack is allocated as system memory, but usually used enough that at least the top page or two will typically be in the cache at any given time.
7. Being part of the stack vs. heap makes no direct difference to access speed -- the two typically reside in identical memory chips, and often even at different addresses in the same memory chip. The main difference is that the stack is normally contiguous and heavily used, do the top few pages will almost always be in the cache. Heap-based memory is typically fragmented, so there's a much greater chance of needing data that's not in the cache.
8. Little has changed with respect to the maximum size of object you should allocate on the stack. Even if the stack can be larger, there's little reason to allocate huge objects there.
9. The primary way to avoid memory leaks in C++ is RAII (AKA SBRM, Stack-based resource management).
10. Smart pointers are a large subject in themselves, and Boost provides several kinds. In my experience, collections make a bigger difference, but the basic idea is largely the same either way: relieve the programmer of keeping track of every circumstance when a particular object can be used or should be freed.

Answer 2

1.How big can the stack get ? Is it processor/architecture/compiler dependent ?

The size of the stack is limited by the amount of memory on the platform and the amount of memory allocated to the process by the operating system.

2.Is there a way to know exactly how much memory is available to my function/class stack and how much is currently being used in order to avoid overflows ?

There is no C or C++ facility for determining the amount of available memory. There may be platform specific functions for this. In general, most programs try to allocate memory, then come up with a solution for when the allocation fails.

3.Using modern compilers (say gcc 4.5) on a modern computer (say 6 GB ram), do I need to worry for stack overflows or is it a thing of the past ?

Stack Overflows can happen depending on the design of the program. Recursion is a good example of depleting the stack, regardless of the amount of memory.

4.Is the actual stack memory physically on RAM or on CPU cache(s) ?

Platform dependent. Some CPU's can load up their cache with local variables on the stack. Wide variety of scenarios on this topic. Not defined in the language specification.

5.How much faster is stack memory access and read compared to heap access and read ?
I realize that times are PC specific, so a ratio is enough.

Usuallly there is no difference in speed. Depends on how the platform organizes its memory (physically) and how the executable's memory is laid out. The heap or stack could reside in a serial access memory chip (a slow method) or even on a Flash memory chip. Not specified in the language specification.

6.I've read that it is not advisable to allocate big vars/objects on the stack. How much is too big ? This question here is given an answer of 1MB for a thread in win32. How about a thread in Linux amd64 ?

The best advice is to allocate local small variables as needed (a.k.a. via stack). Huge items are either allocted from dynamic memory (a.k.a. heap), or some kind of global (static local to function or local to translation unit or even global variable). If the size is known at compile time, use the global type allocation. Use dynamic memory when the size may change during run-time.

The stack also contains information about function addresses. This is one major reason to not allocate a lot of objects locally. Some compilers have smaller limits for stacks than for heap or global variables. The premise is that nested function calls require less memory than large data arrays or buffers.

Remember that when switching threads or tasks, the OS needs to save the state somewhere. The OS may have different rules for saving stack memory versus other types.