gamedevlists-windows

RE: [GD-Windows] autodocument max stack usage

[Brian H. <bri...@py...>]

> I take it you're not a fan of alloca() :-)

Speaking of alloca(), I'm on the record for thinking it's one of the
least understood and most underutilized functions out there.  Incredibly
handy when you're worried about memory fragmentation.

> Unfortunately, pretty much any executable will link against 
> the standard C library, which uses recursion in parts, so 
> even if your program doesn't use recursion, there's no way of 
> proving that your stack size is enough (and no way for a tool 
> to report on potential maximum stack usage).

More important, why is the size of the stack an issue, other than for
informative reasons?  I generally just crank the hell out of my stack in
the linker settings.  It shouldn't have any side effects, assuming I
don't use all of it.

Brian

RE: [GD-Windows] autodocument max stack usage

[Brian H. <bri...@py...>]

 
> I know it happens to everyone, Brian included, with his hash 
> distribution posts. But wonder if we can ask people can hold 
> that back a bit?

People are trying to help.  Often someone asks a question and the proper
answer may not be a direct answer, but instead "Why are you trying to do
this?" to perhaps solve it a different.  For example, if someone says
"How do I optimize my bubble sort?" it would be reasonable to ask in
return "Why are you using bubble sort?" =)

Brian

Re: [GD-Windows] autodocument max stack usage

[Corrinne Y. <cor...@sp...>]

----- Original Message -----
From: "Brian Hook" <bri...@py...>
To: "'Gamedevlists-Windows@Lists. Sourceforge. Net'"
<gam...@li...>
Sent: Thursday, October 18, 2001 2:36 PM
Subject: RE: [GD-Windows] autodocument max stack usage


> More important, why is the size of the stack an issue, other than for
> informative reasons?  I generally just crank the hell out of my stack in
> the linker settings.  It shouldn't have any side effects, assuming I
> don't use all of it.

-- Mmm ... there appears to be possibly some misunderstanding of why stack
watching is important in this day and age. Apologies if the information
below is elementary, but just in case either of you are not aware, the
following are some of the reasons stack watching yields a better user
experience.

-- The information I have collated is overall stack usage distribution
during runtime during development of the project as it grows bigger. It is
also interesting to see where it is using too much stack and maybe it can be
taken down.

-- Therefore it is _extremely possible_, and _extremely informative_ , to
find out how much stack the modules are using, not counting that used by
other libs, and windows dll.

-- An application user should not ever experience stack fault, or failure to
start app on their system because there is not enough initial stack.

-- (Unless their machine really sucks. :) )

-- The other thing I want to minimize for both performance and robustness
reasons is any runtime stack frame allocation.

-- On XP, as an example, accidental excessive stack frame locks can be a
performance hit. As well as a robustness concern (i.e., it can fail).

-- Another reason is (since I had programmed on consoles as well as PC
applications) cross console and cross platform behavior. One can assume
pushing and popping of stack frames for most PC operating systems, but one
cannot assume the same or similar performances on other operating systems
and consoles.

-- By being able to have a snap and a report how how much stack (and how it
is distributed) on 1 platform (i.e., in Visual C). I can very easily move it
to other platforms that may have more limited memory requirements.

-- I generate the same anal autodocumentation for my memory heap as well.
Not only how big my full heap is and needs to be, but also traces of which
modules is using how much at what time.

-- This information is very helpful when moving to platforms and giving a
quick idea where and how to cut.

-- Still looking for posts that actually _ANSWER_ the post _TOPIC_!

-- Not looking for or reading more posts on why it shouldn't be done or
can't be done.

-- I guess this is similar to Brian asking about if his distribution is
normal, and getting hundreds of hash function back. :)

-- As for _alloca, it can be used as the fallback for obtaining scratch
memory, but before your scratch queue is initialized.

-- _alloca can be a handy function for temp buffer.

-- But if you roll your own (temp buffer allocation), you can do even more
range safe checks on all your memory situations.

-- Again, in XP, it is highly naughty to read memory one does not own. If
some of your memory comes from _alloca, you would not have the real "pointer
min" and "pointer max" for a heap range check before walking it, or before
reading your "magic." Since _alloca can come from (relatively) anywhere.

-- But if you roll your own temp stack, you can safely read your magic since
you know for sure you own that.

-- I have recently become a big fan of handle as much of your own memory as
you can, in the simplest manner possible (i.e., no fancy realtime inplace
compaction schemes).

-- No, and I hold back in custom frame stack allocation schemes as well ...
though it is possible, though again too naughty. :)

-- So, back to the _TOPIC_. Is there a linker output for it, or not. (even
on the module level).

P.S. Hate to be cross, but I hate that at this list and some other places,
one posts a question, and gets a lot of posts explaining really simple and
obvious things that we should all already know.

I know it happens to everyone, Brian included, with his hash distribution
posts. But wonder if we can ask people can hold that back a bit?

RE: [GD-Windows] autodocument max stack usage

[Roland <ro...@wi...>]

> -- So, back to the _TOPIC_. Is there a linker output for
> it, or not. (even
> on the module level).

I don't know, if there's a linker output for it... (now I'm gonna get
flamed...:-))... but ....

I did a little app a while back, where I totally removed the C runtime
from the final executable. (The purpose was to get a tiny tiny Win32
app). Without linking to the C runtime, I had to implement all runtime
functions used myself or let the compiler generate intrinsic
functions. Somehow there was one function missing in DEBUG or RELEASE
builds (don't remember which one it was, but I guess it was DEBUG):
_chkesp()

I looked at the assembly source and as far as I know this function was
called on almost every function leave. I think it's used to verify
that a function didn't mess with the stackframe...

Below is my implementation to get the linker happy, but I think you
might blow this function up a bit and monitor the ESP/EBP contents a
get some idea on stack usage from that...

Just a thought
roland


SmallIO.cpp:
.....
extern "C" {
__declspec(naked) void __cdecl _chkesp(void)
{
    _asm
    {
        ret 0;
    }
}
};
.....