Thanks Jonathan for your msg about OS/2 crash-proof?, on 26
09-26-1994

JP>   Nope.  If a process requires 512Mb of virtual memory on a
JP> system with
JP>   32Mb physical memory, it will need 480Mb swapfile.
JP> 

Thats not true to my knowledge. Virtual memory needs no backing
storage until commited. I can allocate a humungous memory buffer,
but not commit any of it. The only thing that has happened is that
OS/2 has carved out that area of memory 'addresses' not that
memory. This memory can then be committed as needed a page at a
time. The database manager would then apply a LRU algorthm of some
type to map the larger virtual space into the available physical
memory. It just decommits the pages of a record in the virtual
space. This frees the backing physical page for reuse, and
'resets' the access trigger so that the next reference to the
virtual page will cause the access fault again.

JP>  A specious argument, IMO.  If you will not ever need to
JP> commit all of
JP>   the 2Gb, then don't allocate the address space, and only allocate the
JP>   maximum that you will ever need.
JP> 

They are doing it for speed. If they map a file on disk to a 1
Gig virtual address space, then the operating system will allow
them to swap in any records that are accessed very quickly via an
exception (without the client code ever having known about it.)

JP> On the one hand, in the limiting case the file will be 2^32 -
JP> 1 bytes
JP>   long, taking up the whole of the virtual address space for the process
JP>   and leaving 1 byte for code, data, and stack.
JP> 
JP>   On the other hand (in case you were about to say "but no file will
JP>   ever be that large"), if memory mapped files are to be limited to a
JP>   "reasonable" size, I'd still say that 512Mb *is* a
pretty reasonable
JP>   size, especially as it is larger than a lot of people's total hard
JP>   disc.
JP> 

Well I wasn't actually advocating taking up the whole process'
memory. But there is a lot of space between 512Meg and 2 Gig. And
512Mg is not a reasonable size for many databases. The limitations
that we are talking about here are why a lot of database vendors
are porting to NT and getting away from OS/2. They are using
exactly the kind of trick I am discussing here. In fact the 2Gig
limitation for files is a problem for many database vendors. They
don't want to rewrite their applications to have to break up
databases across multiple files just to support OS/2.

___
 X KWQ/2 1.2b X I'm an OS/2 developer...I don't NEED a life!

--- Maximus/2 2.01wb