Excerpted from message dated 03-27-97, Denis Tonn to David Noon:

DN> That is the reasoning behind "sparse" stack allocation.
DN> 
DN> Just allow the program to use a huge amount and let it 
DN> commit page frames of memory as it needs them. That is why Murray's
DN>program with 2MB of stack consumes only 216KB of real memory.

DT> 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. 

Hi Denis--

    It is my understanding, after reading your post very carefully and
rereading Chapter 6 ("Memory Management") of my hard-copy Warp 3 manual
"Control Program Programming Guide" (IBM p/n G25H-7101-00), that
"sparse
stack allocation" is a technique used by "smart" OS/2
compilers to make
sure that the running program makes use of the OS/2 "sparse memory
allocation" facility to commit stack space only as needed.  I also
believe that all IBM compilers designed for OS/2 2.0 (and later), as
well as some other vendors' compilers, make proper use of this
capability.  There are some compilers (e.g., Borland BCOS2) that don't.
If you have OS20MEMU (or equivalent) available, It is not hard to test
whether or not the compiler(s) you are using have this capability.

    I tried a small test to see if using MEMMAN=COMMIT in my CONFIG.SYS
would change anything in the actual memory being used by my small PL/I
utility.  (There was a typo in my original post to Henk: the "in-mem"
storage taken up by my little PL/I utility [after the second thread
kicks in] is 116 KB, not the 216 KB in the original post.)

    I added "MEMMAN=COMMIT" to my CONFIG.SYS file and rebooted.
Recompiled and relinked the program.  The resulting .EXE file was
identical with that of the previous version.  Ran the program and
measured memory usage with OS20MEMU.  After the second thread kicked in,
"owned" storage was 2592 KB and "in-mem" was 116 KB;
both identical to
when running under the default "NOCOMMIT" configuration.  OS20MEMU did
not show anything in SWAPPER.DAT in either case.

    It is my understanding (from reading the "help" information--not
always a completely reliable source) that all "MEMMAN=COMMIT" does is to
make sure there is enough space reserved in SWAPPER.DAT to handle the
needs of the running programs, and to run up a flag if any program would
be expected to run out of swap space.  In my case, SWAPPER.DAT is
initialized to 30 MB, and OS20MEMU very rarely shows that anything has
been written to it (usually only after compiling and linking a large
program).  Further explanation of what the COMMIT attribute actually
does would be appreciated.

DT> 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. 

    I don't have any idea of how the compiler/linker combination handles
the "sparse stack allocation" up to the maximum specified in the linker
command, but they do.  Earlier experiments showed that increasing the
stack size specified in the linker command increased the "owned" storage
accordingly, but left the "in-mem" amount unchanged.

    For the record, I am running under the initial release of red Warp 3
plus FixPak 5.  The compiler and linker used for this test was the
(demo) IBM PL/I for OS/2, v1.R2.05 (1.2 + CSD #1), and ILINK v 01.02.00.

    Regards,

          --Murray

___
 * MR/2 2.25 #120 * Never get carried away by a flood of logic

--- Maximus/2 2.02