Original from  Patrick Haller  to Vadim Bugrov on 11-12-1996
Original Subject: I couldn't get xalloc exe

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

  VB> Next my program stops with a system error "there are not
enough memory". 
  VB> 1) How can I know if my program has got a virtual, not 
  VB> a physical memory? 

PH> You'll never know. This is exactly the advantage of a virtual memory system.
 
  VB> 2) Why xalloc exception do not thow to me? 

PH> With the standard setup for the memory manager, OS/2 will NEVER give you a 
PH> ERROR_NOT_ENOUGH_MEMORY for a DosAllocMem request. It grows 
PH> the swapfile and if it reaches it's maximum size, HARDERR 
PH> will offer you a dialog to terminate your application. 
PH> Unless you set MEMMAN=NOSWAP (anything but recommended for 
PH> the normal user :) you won't be able to catch the Borland 
PH> Runtime Exception as the runtime itself won't get 
PH> ERROR_NOT_ENOUGH_MEMORY.

 Rather than memman=noswap, try memman=commit.. It will preallocate 
swapspace at the time of your allocmem, and if there is not enough 
will give the above indication. 

PH> The "there are not enough memory" message you got
indicates that the system 
PH> ran out of page table entries. For Intel boxes you have 
PH> 8192 page table entries (GDT) of which already about 4000 
PH> are occupied when OS/2 is booted (depending on other 
PH> applications running). So if Borland's Runtime Heap Manager 
PH> doesn't properly keep track of it's objects, it trashes the 
PH> system page table.

 Not really. You are getting page tables mixed up with desciptor 
tables. Each process has it's own LDT. Each process has it's "own" set
of page tables, although many pages are shared with the system 
(supervisor state usually needed). GDT entries and page table entries 
have nothing to do with each other - they are different layers in the 
logical to linear to physical address. 
 There are only 2 GDT entries used for 32 bit apps. Selector 5B for
code and 53 for data. Each of these allows an app access to a
potential 448 MB address space (minus any shared addresses). 

 I suspect what you are thinking of is the situation when the shared 
arena grows down to the highest address that the application with the 
largest private arena has grown to. If this condition is reached, then
only this app will fail a private alloc, but ALL processes will fail a 
shared alloc.  This is usually caused by a memory leak. In the private
address space of some app, or an app that is allocating shared
addresses.


   Denis       

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