To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Re: X-32 and VM.
From:	alane AT wozzle DOT linet DOT org (J. Alan Eldridge)
Date:	Mon, 11 Jan 93 20:29:20 EST
Organization:	Disorganization

>From src4src!mcdhup!rutgers!proto.com!joe Mon Jan 11 17:51:13 1993 remote from wozzle
Received: by wozzle.linet.org (1.65/waf)
	via UUCP; Mon, 11 Jan 93 19:37:13 EST
	for alane
Received: from mcdhup by src4src.linet.org with uucp
	(Smail3.1.28.1 #3) id m0nBXyM-00028vC; Mon, 11 Jan 93 17:51 EST
Received: by mcdhup (/\==/\ Smail3.1.25.1 #25.9)
	id <m0nBWml-00009gC AT mcdhup>; Mon, 11 Jan 93 16:35 EST
Received: from zeus.ieee.org by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) 
	id AA15683; Mon, 11 Jan 93 15:23:26 EST
Received: from netcomsv.netcom.com (uucp2.netcom.com) by zeus.ieee.org [ieee.org] (4.1/Z-2.95)
	id AA11159; Mon, 11 Jan 93 15:23:15 EST
Received: from proto.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1)
	id AA29205; Mon, 11 Jan 93 12:21:11 PST
From: Joe Huffman <src4src!mcdhup!rutgers!proto.com!joe>
X-Mailer: SCO System V Mail (version 3.2)
To: wozzle.linet.org!alane
Subject: X-32 and VM.
Cc: proto.com!joe
Date: Mon, 11 Jan 93 11:11:16 PST
Message-Id:  <9301111111 DOT aa18042 AT proto DOT COM>

Doug sent this to me several days ago and I just now got around to forwarding
it on to you.  If you like you can send it on to others that it might be of 
interest to.

Thanks for giving us this opportunity to get some more visibilty.

Joe Huffman
FlashTek, Inc.                  FlashTek, Ltd.
121 Sweet Ave                   Partnership House
Moscow, Idaho 83843             Grantham, Lincs
U.S.A.                          NG31 9ST  England

FAX:    208-882-7275            FAX:   +44-476-61382
Voice:  208-882-6893            Voice: +44-476-74108
Orders: 800-397-7310
Email:  flashtek AT proto DOT com      Email: flashtek AT cix DOT compulink DOT co DOT uk
CIS:    71332,203               CIS: 100042,1673
----- 
Hello,
 
Regarding DOS extenders and what can be done if the VM manager runs out of 
space on the hard drive.  If a VM manager finds itself in a position where it 
needs to swap a page yet the hard drive is full, there isn't much choice but 
to terminate.  I suppose there could be a feature whereby control could pass 
to an application handler (located in a locked memory region) which would free 
up some memory or disk space thus giving the VM manager some breathing room.  
The OS2 2.0 kernel seems to have an internal feature like this although I 
don't think applications can get at it. 
 
Probably the best approach however is to prevent this situation from happening 
in the first place.  First of all, the VM manager should not allow the 
application to allocate a quantity of memory which it cannot support with the 
system resources it has available to it.  X-32VM bases its maximum allocatable 
memory on the available disk space and the available physical memory.  It 
calculates a conservative maximum which it should be able to support in the 
worst case and will fail memory allocation calls which would cause the total 
memory to exceed this maximum.
 
There is one situation which X-32VM does not protect against but which the 
application designer can prevent given the correct understanding of the 
problem.  X-32VM does not allocate disk space at the time the application 
allocates memory but rather as it actually needs the disk space to support VM.  
Thus it may allow the application to allocate 20 megabytes of memory while 
there is 20 megabytes of free disk space.  Then suppose the application fills 
up the hard drive with new files (since X-32VM didn't tie up the disk space at 
allocation time), then the application starts accessing all this memory which 
it allocated previosuly.  In this case, X-32VM will terminate unexpectedly 
with an error message.  Programmers are warned of this possibility and given 
preventative methods in the X-32VM programmers manual.

doug AT proto DOT com

- Raw text -