Confused about Memory

This is a discussion on Confused about Memory within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by King Mir What would be wrong with keeping an object pool on the stack? Well for one... ...

  1. #16
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,066
    Quote Originally Posted by King Mir
    What would be wrong with keeping an object pool on the stack?
    Well for one... a stack overflow.
    ...and secondly, more often then not, most of those objects will be sitting idly when they don't need to be there at all. When you write more complex programs, you have to manage your memory and keep only what you need. You could keep static objects for all the rendering information for every map you make, but what's the point if you only render one map at a time.

    I remember one of the first real programs I wrote was a trivia program. It have several games each with 10 questions. I decided to hard code all of the questions into strings, which totaled to about 400 strings between the questions and multiple choice answers. I only needed maybe 50 strings in memory at any given game. Not saying this is a prime example, but even when you get better at programming, there could still be bad memory management.
    Sent from my iPadŽ

  2. #17
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,638
    Crashing because of stack overflow is your friend. It lets you know in the most violent way possible that you failed at programming and need to do better. That's worth something.
    Furthermore, what defines the max size of the stack? If stack sizes vary by machine, a program might run fine on one machine, but fail on another.
    Well the stack is sufficiently huge for that kind of stuff: it's really a combination of the OS and compiler magic that allows the stack to work the way it does, but the restriction needs to be there otherwise you could make the stack so huge that it interferes with other programs.
    Last edited by whiteflags; 06-17-2006 at 11:47 PM.

  3. #18
    Registered User
    Join Date
    Apr 2005
    Posts
    76
    isn't the stack size determined by the amount of RAM and virtual memory of the computer?

    How C Programming Works

    btw...thanks for the link citizen...way better understand with memory... and pointers

  4. #19
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,638
    > isn't the stack size determined by the amount of RAM and virtual memory of the computer?
    Yeah but the OS does that kind of work. And in particular with functions your compiler will put in code to teach the OS how to build the function's stack frame.

    As for the article, just don't pick up the bad habit of casting malloc without knowing what that could do. There are details in the FAQ about why that is bad, if you ever decide to code in C. Also be aware that new has a couple of ways to tell you allocation has failed. By throwing an exception:
    Code:
    #include <stdexcept>
    try {
       int *p = new int;
    } 
    catch (std::bad_alloc &error) {
       // spit out an error message and close or something
    }
    Or you can force new to return 0:
    Code:
    #include <new>
    int *p = new (std::nothrow) int;
    if (!p)
       // error message again...
    Last edited by whiteflags; 06-18-2006 at 01:09 AM.

  5. #20
    Registered User
    Join Date
    Apr 2006
    Posts
    2,021
    Quote Originally Posted by citizen
    Crashing because of stack overflow is your friend. It lets you know in the most violent way possible that you failed at programming and need to do better. That's worth something.

    Well the stack is sufficiently huge for that kind of stuff: it's really a combination of the OS and compiler magic that allows the stack to work the way it does, but the restriction needs to be there otherwise you could make the stack so huge that it interferes with other programs.
    Stack overflow would be less of a problem is there was a way to split the stack between two memmory blocks.

    Sufficently huge is always a relitive term. If I have a big program, I'm more likely to run out of stack memmory. If I have a small program, it's wasteing memmory with a large stack.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  6. #21
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,638
    Maybe I need to approach my replies in a different way.

    Memory is a finite source. Period.

    Even if you split up the stack for your program, that is not solving the stack overflow problem but just delaying it. No matter how many times you split up the stack you can still run out of memory. You can also run out of heap memory. So if you continually crash because of stack overflow, instead of blaming memory for your programming problems, maybe you need to turn a critical eye to the code.

    Applications that are ready for the consumer typically handle memory very well and don't run out. You may run out on occassion but at least it's not every single time.

  7. #22
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    As an aside:
    > How does the computer then deside before runtime how much stack space a program will need?
    It kind of doesn't. The stack is pretty much the same size for every program I think. I don't know how to prove it though.
    Specific to Windows (found on MSDN):
    Code:
    HANDLE CreateThread(
      LPSECURITY_ATTRIBUTES lpThreadAttributes,
      SIZE_T dwStackSize,
      LPTHREAD_START_ROUTINE lpStartAddress,
      LPVOID lpParameter,
      DWORD dwCreationFlags,
      LPDWORD lpThreadId
    );
    dwStackSize
    [in] Initial size of the stack, in bytes. The system rounds this value to the nearest page. If this parameter is zero, the new thread uses the default size for the executable. For more information, see Thread Stack Size.
    --- (Thread Stack Size)---
    Each new thread or fiber receives its own stack space consisting of both reserved and initially committed memory. The reserved memory size represents the total stack allocation in virtual memory. As such, the reserved size is limited to the virtual address range. The initially committed pages do not utilize physical memory until they are referenced; however, they do remove pages from the system total commit limit, which is the size of the page file plus the size of the physical memory. The system commits additional pages from the reserved stack memory as they are needed, until either the stack reaches the reserved size minus one page (which is used as a guard page to prevent stack overflow) or the system is so low on memory that the operation fails.

    It is best to choose as small a stack size as possible and commit the stack that is needed for the thread or fiber to run reliably. Every page that is reserved for the stack cannot be used for any other purpose.

    A stack is freed when its thread exits. It is not freed if the thread is terminated by another thread.


    The default size for the reserved and initially committed stack memory is specified in the executable file header. Thread or fiber creation fails if there is not enough memory to reserve or commit the number of bytes requested. The default stack size used by the linker is 1 MB. To specify a different default stack size for all threads and fibers, use the STACKSIZE statement in the module definition (.def) file. The linker rounds up the specified value to the nearest 4 bytes.

    To change the initially committed stack space, use the dwStackSize parameter of the CreateThread, CreateRemoteThread, or CreateFiber function. This value is rounded up to the nearest page. Generally, the reserve size is the default reserve size specified in the executable header. However, if the initially committed size specified by dwStackSize is larger than the default reserve size, the reserve size is this new commit size rounded up to the nearest multiple of 1 MB.

    To change the reserved stack size, set the dwCreationFlags parameter of CreateThread or CreateRemoteThread to STACK_SIZE_PARAM_IS_A_RESERVATION and use the dwStackSize parameter. In this case, the initially committed size is the default size specified in the executable header. For fibers, use the dwStackReserveSize parameter of CreateFiberEx. The committed size is specified in the dwStackCommitSize parameter.

    The SetThreadStackGuarantee function sets the minimum size of the stack associated with the calling thread or fiber that will be available during any stack overflow exceptions.
    **EDIT**
    Sufficently huge is always a relitive term. If I have a big program, I'm more likely to run out of stack memmory. If I have a small program, it's wasteing memmory with a large stack.
    This is an ideal. A 'big' program, i.e. one that comes with 3 install CD's, will not necessarily use more stack space than a 'small one' (100kb standalone exe). In general, I believe the primary cause of increased stack use is function call depth.

    If call depth gets larger than say, 50, there's probably something quite wrong with the program architecture (barring recursive algorithms). Say we're pigs and allocate an average of 4kb of buffers in each function call (anything larger goes on the heap since it probably needs to persist, i.e. so you don't have to re-load the data from disk each time you want it). The buffers are much larger than function call overhead, so we will assume that to be negligible. This means we require a maximum of 200kb of stack space in a worst-case scenario for normal operation. Give the app 512kb or 1mb and it should be happy for a long time. I suggest that the *only* way you will run out of stack space is by gross inefficiency (i.e. recursion instead of a loop, for iterating a list, while allocating large stack buffers inside the recursive function).

    On the other hand, your system has at least 512mb of RAM, and probably as much swap space. That 'huge' 512kb is 0.1% of your resources. So who cares?
    Last edited by Hunter2; 06-20-2006 at 01:12 PM.
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  8. #23
    Registered User
    Join Date
    Apr 2006
    Posts
    2,021
    Yeah, I'm going to concead here.

    One of the things a had misread/forgot was that Global and static variables are defined in a seperate block of memmory not part of the stack. Although they are still considered "stack variables" they are apparently not part of the same memmory block (at least according to that article).

    I still hold however that there is nothing inherrently wrong with storing fixed size array data in static object members such as with Singletons. Object pool example I had earlier included.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Problems with shared memory shmdt() shmctl()
    By Jcarroll in forum C Programming
    Replies: 1
    Last Post: 03-17-2009, 10:48 PM
  2. Replies: 4
    Last Post: 01-13-2008, 01:14 AM
  3. Copying memory, pointers and the like.
    By psychopath in forum C++ Programming
    Replies: 34
    Last Post: 12-12-2006, 12:37 PM
  4. Locating A Segmentation Fault
    By Stack Overflow in forum C Programming
    Replies: 12
    Last Post: 12-14-2004, 12:33 PM
  5. Memory leak trackers
    By Darkness in forum A Brief History of Cprogramming.com
    Replies: 5
    Last Post: 11-30-2004, 01:03 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21