Original from  Murray Lesser  to Denis Tonn on 03-31-1997
Original Subject: Trap 0005

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

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

 Your understanding is essentially correct. MEMMAM=COMMIT will 
"reserve" space in the swapper for all allocations that an application
does. It does not actually "put" anything there, just makes sure that 
the space is available if needed. A small example might help here: 

 Take an application that allocates say 200MB of memory (don't care 
what for). OS/2 (normal NOCOMMIT option) will return an address and a 
good RC. At this point, the "memory" does not exist anywhere, not in 
RAM, not in the swapper. Nothing has happened except that the OS/2 
memory control blocks have been updated to indicate it is "OK" to use 
this address range. When the application trys to use memory in this 
address range (read or write) then the memory will be "backed" at that
time (possibly by swapping something out first). If the app continues 
to "use" all this memory it will eventually need all 200MB and your 
swapper will have grown to accomodate this - unless the swapper is on 
a drive with say 150MB free. Obviously, the swapper cannot grow to 
the 200MB size so you will end up with an error telling you that you 
have run out of swap space. The app (and the system) may die. 
 Now try the same app with MEMMAN=COMMIT. At the time of the 200MB 
allocate, the system will attempt to "grow" the swapper to accomodate 
a 200MB usage before it returns to the app. This will insure that 
there is sufficient resources to "back" this memory regardless of how 
much of it the app uses. If it cannot grow the swapper enough, it will
return a bad allocate RC to the app. 

 In your example, you already have a 30MB swapper, and it is not being
touched by normal apps. Run your app, and the system will "reserve" a 
portion of that 30MB for your app's potential growth. It is already 
large enough, so the swapper does not need to grow further. It does 
not use any portion of this space, it is just "reserved" (similar to 
"reserving" the memory addresses without backing it with ram for the 
original allocate). 
 If you tried the same test with a 1MB swapper, you should see it 
grow. 

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

 Ah.. You have seen the result of "sparce memory allocation" already.
What OS2MEMU is showing is the range of addresses "available" to the
app vs the amount of RAM in active use. It does not show the amount of
"memory" used, addresses that have been used but not currently active
(swapped or discarded) on a per process basis. The above shows the 
effects of OS/2's sparse memory allocation. 

 It is sometimes beneficial to think of an app allocating "address 
ranges" rather than "memory" (and more accurate in the internal system
context). These addresses can be shared, private, usable, unusable, 
writable, readonly, backed, in ram, on disk, etc.. Using this way of 
thinking (programmers usually think in terms of memory) enhances the 
understanding of the differences between the "COMMIT" flag on 
DOSALLOCMEM (makes the addresses usable by the app) vs the "COMMIT" 
flag on the MEMMAN config.sys statement (causes the system to reserve 
space for backing). 
 I don't know of a single tool (other than the debug kernel and dump 
formatter - and it is not "user friendly") that allows access to the 
total "picture" of system and application address usage. Even if one
existed, the results would probably be too confusing for most people
to interpret (Theseus comes close). The difference between swapped and 
discarded pages, shared and private addresses, and shared and private
memory (different!) are more than most people want to deal with, never
mind the details of the above kinds of "flags" on the different
address ranges. 

 I went through the memory management section of the OS/2 CP Ref, and 
could not find any reference to a "sparse stack", but did find lots of
references to "sparse memory objects". The CP documentation ignores
the effects of OS/2's default "sparse memory management" (MEMMAN=),
but references the effects of "COMMIT/NOCOMMIT" on the DosAllocMem API
(usable vs unusable addresses) and talks about the usage of Guard
Pages for managing stack usage. This is where I get my understanding 
of a "sparse stack". 

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

   Denis       

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