Original from  David Noon  to Henk Den Adel on 03-25-1997
Original Subject: Trap 0005

                         ---------------------------------------

  MP> Just make your stack large enough.
 
 HA>Murray Lesser wrote me that excessive stack does not hurt 
 HA>my resources, if the compiler is good, so that will be the 
 HA>solution.
 
DN> That is the reasoning behind "sparse" stack allocation.
DN> 
DN> Just allow the program to use a huge amount and let it commit page frames of
DN> memory as it needs them. That is why Murray's program with 2MB of stack
DN> consumes only 216KB of real memory.

 I have been reading through this thread (picked up a bunch of 
packets at once), and believe both you an Murray are correct, but I 
think that the reason Murray's program only uses 216KB of memory
is not because of "sparse stack allocation", but because of the
default OS/2 "sparse memory allocation" (IE: it does not allocate RAM
until memory is used). If he used MEMMAN=COMMIT (default is NOCOMMIT)
in his config.sys, his program would probably "use" all of his 
staticly assigned 2MB of stack. Most of this would be seen as
preallocated swap space. 
 "Sparse stack allocation" would be under control of the application 
and usually implemented using guard pages and an exception handler to
"allocate on the fly" additional (guard) pages. This allows the
application to monitor it's own stack growth through the exception
handler. 

 Dependence on the OS/2 "sparse memory allocation" is perfectly valid, 
but the app cannot monitor the growth and it can lead to excessive
swapper growth if MEMMAN=COMMIT is used (special situations only). 

 It *is* possible for compiler runtime to automaticly include an 
exception handler and do "sparse stack allocation" transparently, but
I don't see how the linker would have any control over the "stack
size" settings for this case. 


   Denis       

 All opinions are my very own, IBM has no claim upon them
. 
. 
.
--- Maximus/2 3.01