Path: utzoo!attcan!uunet!samsung!think!paperboy!osf.org!lwa
From: lwa@osf.org (Larry Allen)
Newsgroups: comp.sys.apollo
Subject: Re:  Mentor Graphics Mspice.020 server
Message-ID: <3322@paperboy.OSF.ORG>
Date: 6 Feb 90 14:25:50 GMT
References: <9002061400.AA03716@umix.cc.umich.edu>
Sender: news@OSF.ORG
Reply-To: lwa@osf.org (Larry Allen)
Organization: Open Software Foundation
Lines: 45

To be fair (but then, who ever said the world was
fair? :^) and in defense of SR10, the behavior of
requiring backing storage space for all allocated
virtual memory is not only there for JLRUness, as
Dave implies.  The fact is, Apollo received a fair
number of complaints from customers, especially
system vendors, who found it difficult to write
applications that would be robust in the face of
running out of disk space.  The problem is that the
allocation of virtual memory (eg. via the UNIX
malloc(), or via various Aegis calls) would apparently
succeed, but when the process attempted to touch the
memory (and hence had to actually allocate the disk
space for the backing storage), the disk would be
full and the touch would fail.  Unfortunately it's
very difficult to handle a disk-full condition at
this point (in the middle of a page fault); the only
recourse the OS has is to send a signal to the process.
Writing an application that can deal robustly with an
effectively asynchronous signal that can occur during
the first touch of any portion of an allocated data
structure is extremely difficult.

So, in SR10 we took the much more conservative approach
of requiring preallocation of backing storage for all
allocated virtual memory.  As Dave notes, this adversely
affected some applications (eg old Fortran programs)
that allocated huge amounts of virtual memory not intending
to ever use most of it.

I left Apollo about a year ago, so I'm not sure what (if
anything) they've decided to do about this.  Off the top
of my head, the only thing I can imagine is some kind of
option (perhaps a per-object-file stamp??) that tells the
OS "for this application, don't preallocate backing storage".
This seems pretty ugly and hard to administer, as well as
being pretty non-obvious to the "average user".

In any case, it's a very hard problem.  It's a general case
of the problem "how do you allow maximum utilization of a
limited resource without running the danger of overcommitting
the resource and without risking deadlock due to resource
contention?"
						-Larry Allen
						 Open Software Foundation