[lug] Huge stack size--any reason to avoid?

[Amar Vattakandy]

Vince,

I admit I have no familiarity with what your program does, and I write this
solely based on my own experience looking at improperly written code, so
please take it for what it's worth. I think C++ was partially responsible
for making objects behave like instances of first class variables (like
integers etc), so that it was just easy to pass an object into a function,
for example. So, if you have a huge object at any level either on the heap
or the stack, passing it (not a reference or a pointer) into a function
causes a copy created on the stack. So, if there are a few levels of these
function calls, it drains the stack pretty quickly. Again, I am not implying
that this is what is happening in your case, but this is a pretty common
occurrence. If this is the case, more serious than the memory usage is the
wastage of time copying the data into the stack. Obviously the solution is
to pass references around, if it makes sense to do so.

And I have  had developers claiming like you had experienced that the stack
is managed automatically so that you will never have memory leaks if all the
objects are on the stack. While that is usually true, the loss in
performance (copying things into the stack multiple times) usually have to
be balanced against the gains. And more than a few times I have reached the
conclusion that the developers were reluctant to put extra effort into
thinking of object management, hence they put everything on the stack.
Though it might make sense in a lot of cases, esp. if the size and number of
these objects are not that high, I have seen this crippling some serious
programs.

You mentioned that the stack allocation is perfectly reasonable in this
case. I feel that a good thumb rule is to ask yourself (or the developer)
this question. Do I have at any given time, multiple copies of an object on
the stack where a single copy would have sufficed? If the answer is no, for
all practical purposes, it does not matter whether the data structure is on
the heap or the stack. Both are demand paged, and hence resides in the
physical memory or disk depending on the usage statistics. At least I am not
aware of anything that make it faster for the stack v/s the heap in that
regard. But you could argue that stack patterns are easier to predict than
heap accesses and could be optimized by the OS for faster swapping.

So, if the stack usage is reasonable as such, I'd keep it that way. Stimit's
method of user managed heap is a great way to consolidate the overhead of
multiple OS calls and results in a huge performance boost if there are a
billion new/deletes, but keeping the objects on the stack does the same
thing if it makes sense to do so in the program.

Amar

On 10/17/06, D. Stimits <stimits at comcast.net> wrote:
>
> Vince Dean wrote:
>
> >I'm working with some C++ code which puts very large
> >data structures on the stack, large enough that we have
> >to increase the allowable stack size to 512 megabytes:
> >
> >  ulimit -Ss 512000
> >
> >The developers point out that variables on the stack are
> >managed automatically, minimizing the risk of
> >memory management errors.  If the lifetime of the
> >objects is such that they can be managed conveniently
> >on the stack, I can't disagree with that argument, but
> >something still makes me uncomfortable.
> >
> >I understand that there are many cases where the sequence
> >of creating and destroying objects makes it essential to
> >manage memory dynamically on the heap.  This is not such
> >a case.  Stack allocation is perfectly reasonable here.
> >The only issue is the very large size.
> >
> >Are there any practical arguments against putting
> >big data structures on the stack?  We are running Suse
> >Linux on an Itanium system.  Am I likely
> >to run into a Unix or Linux desktop or server machine
> >where it is not possible to set the stack so large?
> >
> >In the end, it is all (virtual) memory, with the
> >stack being allocated at one end of the address
> >space and the heap on the other end.  Is there any
> >reason for me to be concerned about this coding style?
> >
> >
> >
>
> I'd be interested in hearing about the answers. I'm just wondering if
> performance is an issue...somehow (without any proof), I would think
> that a single reference into a heap space would be faster than using the
> stack, especially if you have exceptions enabled (are exceptions
> enabled?). Run it with gprof and see what changes. I also wonder if
> stack space can take advantage of virtual memory via swap as easily as
> heap can...until now I've never thought about that. If you plan to
> allocate and deallocate a lot, I have no doubt that running your own
> memory management (which does not need to be complicated) to cache and
> pool kernel requests and keep most new/delete in user space would be a
> huge performance bonus at that size.
>
> FYI, I'm not a fan of inventing a new crutch as a way of avoiding doing
> the job right to start with. I'd be really curious as to why it is they
> felt the need to do this in the first place, and whether the app has to
> be portable, and whether it'll be on only 64 bit machines (you mentioned
> Itaniums, but perhaps not everyone running it has Itanium).
>
> D. Stimits, stimits AT comcast DOT net
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20061017/666374cf/attachment.html>