Heap, Stack, Free Store

[bana]

If I remember correctly, the free store = heap which is accessed with the new command and the stack is what everything else is put on (int x = 5; ).

• Are both of these actually stored on the RAM?
• Are there any appreciable speed differences towards using either of them?
• The stack holds significantly less than the heap correct?
• When I load something into Ogre (lets say a texture applied to the ogre.mesh) does it put it on the heap?
• What about the various scenemanagers?
• Are there any other noteworthy methods of memory storage?

[sinbad]

1. Yes
2. No, except if you pass things by value through methods which are called hundreds or thousands of times per frame. It's not the stack which is making it slower, it's the fact that you're passing by value when in fact you should be passing by reference / pointer
3. Yes, stack space is limited.
4. All objects are on the heap, since stack objects are deleted on return. They may also consume memory on the GPU (texture do, for example) which is allocated through DirectX or OpenGL API calls.
5. Ditto
6. Memory mapped IO is an interesting one, which allows you to address a file as if it were in memory. Other than that it's just heap and stack these days; the olden days of having to worry about 64k boundaries, code segments and data segments are past. Think yourself lucky

[haffax]

Modern OSs use so called virtual memory. This means every running process (program) has vertually its own 2GB (other OSs other values..) of memory available. Of course most computers don't have this many RAM, so the virtual memory is mapped onto the real hardware memory. Virtual memory can be outsourced to the hard disk, if not enough real memory is available. This is called paging (actually there is more to paging, but I'm not going into detail here, not enough time ).
The virtual memory of such an process is further divided in heap and stack memory. The stack "grows from above", means if some data/address is put onto the stack it gets a smaller memory address than the data that was placed on the stack before. The heap grows from bottom to top, usually.

Data on the stack is usually only needed in a certain context/method, like local variables. The stack is more a procedural memory, where the state of your program is saved. Whereas the heap usually contains the complex data you are working with. Its actually very difficult to describe all this without getting into detail, so I'm a little stuck
here. Hope it helped nevertheless.

Answers in order of your questions:

1. Yes, heap and stack are both placed in the RAM.
2. Not per se, but they are used differently. It is hard to describe, without getting too much into detail. This is not an easy topic.
3. This is most often the case.
4. All Ogre resources are placed into the heap, or into special memory areas called hardware buffers. These Hardware buffers are very efficiently accessed by the graphics card, but you must follow special guidelines when you use them. The Ogre manual contains a whole chapter about these buffers. You should read it.
5. It's up to the respective developers, but they too will probably use heap and hardware buffers for their data.
6. Don't really know. I don't know if the above-mentioned hardware buffers are placed into the process' virtual memory, or if these buffers are in another memory region. Like linux has its "kernel land" and "user land" memory.

[alphabeta]

The previous 2 posts are perfect answers, but just to elaborate

1) Heap and stack both occupy RAM, its just a matter of how they are stored (Objects on the heap generally speaking go where there's room, though it is more complex then that. Objects on the stack operate just like a stack, they go on top, following the procedural flow of your program)

2) The performance of the methods isn't something you should be worried about. Local (inside a function) variables operate on a stack.

In case you're confused about member variables (I think what you really meant by choosing between heap and stack was choosing between keeping objects as members and allocating them with new):
Member variables also operate on the heap, they are included in the object that contains them (when you allocate an object, you're allocating the memory for all its members). When data is tied to an objects lifetime, for example a string for it's name, you should make it a member variable, otherwise make it with new and keep a pointer or reference.

3) The stack is limited, which is what causes a stack overflow. The most common cause of this would be uncontrolled recursion, in which a function calls itself infinitely, constantly adding on top of the stack until it runs out of room. The heap contains all your objects, the stack only contains the PROCEDURAL memory, mainly meaning local variables for functions.

4) Heap, as all objects.
5) Same.
6) Well there are a gazillion ways (including the two examples sinbad and tanis mentioned), but heap and stack are the basic ways in which procedural programs keep their memory.

[temas]

Split memory handling and container topics to here.