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 ; 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 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