How "big" is the run-time stack?

I have some general programming questions:

A stack overflow occurs when the stack gets "too big", so, how much is too big?
Does the run-time stack have a specific size like an array? if so, how is the size determined? by the OS? the compiler?
Is it a dynamic data structure like queues and lists? if so, when does it "overflow"? when the entire physical memory is filled?
Also, if it is a dynamic data structure, does that mean that a running program is physically "fragmented"? does it occupy different seperated spots in the RAM?
Are the answers to these questions OS-dependent? language dependent? compiler dependent?

For me, it is 8 Mb.
It depends on the OS, I think.
On Linux, you can find it by "ulimit -s".
You can find and change it from a running program with the system calls getrlimit and setrlimit.

Quote:

---

Originally Posted by butteflymentor

A stack overflow occurs when the stack gets "too big", so, how much is too big?

---

OS and compiler dependent. By default, on Windows with VC++, it's 1 MB.

Quote:

---

Does the run-time stack have a specific size like an array? if so, how is the size determined? by the OS? the compiler?

---

Yes, it does. It's decided by the compiler and the OS.

Quote:

---

Is it a dynamic data structure like queues and lists? if so, when does it "overflow"? when the entire physical memory is filled?

---

It's not dynamic. Its size is static and it's layout is that of a stack.

Quote:

---

Also, if it is a dynamic data structure, does that mean that a running program is physically "fragmented"? does it occupy different seperated spots in the RAM?

---

The stack is a stack, therefore it does not get fragmented.

Quote:

---

Originally Posted by manasij7479

You can find and change it from a running program with the system calls getrlimit and setrlimit.

---

Just to be explicit, that works only on Linux.

If all Windows programs allocate 1MB of stack memory, how come the Windows Task Manager shows a different RAM usage for each program? What do these numbers represent?

The stack is limited to around 1 MB, but that doesn't mean all programs are limited to 1 MB.
There is also the free store, the heap, which is limited only to the virtual or physical amount of memory available in the system.
Also, the stack does not overflow. What happens when you write after the end of the stack is undefined. You may get an error from the OS, or you may inadvertently corrupt some other data.

So, A pretty huge video game, such as Assassin's Creed would use 1MB of stack memory and the rest is handled by the heap? That doesn't make sense at all.
Another example would be svchost.exe, It is currently using 123MB on my computer, are all the 122MBytes living in the heap?
Also, many programs use LESS than 1MB of memory according to the task manager, does the task manager count only the used portion of the program's stack?

Quote:

---

Originally Posted by butteflymentor

A pretty huge video game, such as Assassin's Creed would use 1MB of stack memory and the rest is handled by the heap? That doesn't make sense at all.

---

Why does that not make sense to you?

Quote:

---

Originally Posted by butteflymentor

So, A pretty huge video game, such as Assassin's Creed would use 1MB of stack memory and the rest is handled by the heap? That doesn't make sense at all.

---

Makes perfect sense to me.

Quote:

---

Another example would be svchost.exe, It is currently using 123MB on my computer, are all the 122MBytes living in the heap?

---

Pretty much.

Quote:

---

Also, many programs use LESS than 1MB of memory according to the task manager, does the task manager count only the used portion of the program's stack?

---

Memory management is a complex world. For one, you must divide memory into committed, reserved, free, shared and other.
Though your program may have allocated some memory (eg 1 MB for the stack), you may not be using it all, and therefore the memory manager won't show it.
A lot of this is low-level details that form the basis on how modern operating systems are built.

Quote:

---

Why does that not make sense to you?

---

Quote:

---

Makes perfect sense to me.

---

I admit that there is not a single logical argument against this, guess it does make sense :P

Thanks for the help.

I seriously doubt AC is using the full 1mb of stack. More likely they are using dynamic memory pools for their objects. The chunk of memory is pre-allocated and then a class is responsible for dividing this up into equal chunks and doling them out to users. There are also stack-based memory allocators that use dynamic memory like a stack. They are extremely fast but have some interesting behavior when you go to clean up since they are stack based. Most games use a combination of pools and stacks for their memory management systems and they will vary from platform to platform. I invite you to read Game Code Complete, 2nd ed. for more information about the real world use of these types of constructs and how they are used in the industry.

I have a 20KB program which I programmed myself, I never use malloc or any other heap memory allocation function, yet the Task Manager shows a usage of 2.7MB, how do you explain this? The program is based on Win32, do the win32 functions use heap memory?

Based on what you use, there may be a lot of "book keeping" data in memory. Also remember that globals, static variables, and other things such as resources, the actual code, etc, also gets loaded into memory and counts towards your total usage.
Then you must understand that there are different ways of showing "how much memory" a program is using. There is working set, private bytes, shared bytes, commited memory, shared memory, virtual size, etc.

Is code loaded into the heap or the stack? or both? can the programmer control that?

The code isn't loaded to the stack, because it's meant for local variables which you can push and pop.

Code is loaded "somewhere else" by the OS. The allocation/de-allocation/loading of code is the OS's job. In many cases, the OS won't load the entire program into memory, either. Parts of the program are loaded when needed.

It's neither stack nor heap.