Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!gatech!hao!husc6!sri-unix!sri-spam!mordor!lll-tis!ptsfa!ihnp4!upba!mcdchg!usenet
From: boba@iscuva.ISCS.COM (Bob Alexander)
Newsgroups: comp.unix
Subject: UNIX Facilities for Interpreters
Message-ID: <881@mcdchg.UUCP>
Date: Thu, 18-Jun-87 09:18:37 EDT
Article-I.D.: mcdchg.881
Posted: Thu Jun 18 09:18:37 1987
Date-Received: Mon, 22-Jun-87 03:41:33 EDT
Sender: usenet@mcdchg.UUCP
Organization: ISC Systems Corporation, Spokane, Wa.
Lines: 102
Approved: usenet@mcdchg.UUCP

Modern, memory managed operating systems (like UNIX) have addressed
quite nicely certain special requirements of executable files.  In
particular (1) the file (text and data) need not be loaded into memory
in its entirety to begin executing, and (2) the pages can be shared
among processes that are executing them (both on disk and in memory).

As far as I know, those capabilities are not made available to
interpreters for their pseudo-code and data, even though they would be
equally as applicable as they are to "real" programs.  If 15 users are
running a program written in an interpretive language, the interpreter
code is shared, but the p-code exists separately for each user.  This
results in a major disadvantage in the use of interpretive languages to
produce production programs.  Interpretive systems are in quite wide
use today (e.g. shells, SQLs, (((Lisp))), Icon, etc., etc., [even
BASIC]), and as processor speeds increase, use of interpreters will
likely continue to grow.

There are a few ways of working this problem with existing UNIX
facilities, but the ones I've come up with so far are kluges.  My
reason for posting to this newsgroup is to get your reaction to a
possible new UNIX facility for this purpose.  I'll express my
suggestion in SVID format, sort of:

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

NAME

   vread -- read from a file into memory [but not really, maybe].

SYNOPSIS

   int vread(fildes, bufptr, nbyte)
   int fildes;
   char **bufptr;
   unsigned nbyte;

DESCRIPTION

   The function "vread" attempts to read "nbyte" bytes from the file
   associated with "fildes" into an allocated buffer whose address is
   returned in "bufptr".  This function is similar to read(ba_os)
   [read(ba_os) is SVIDese for read(2)] except for its implications
   concerning virtual memory and that it allocates a buffer rather than
   being given one.

   In a memory managed system, the contents of the file are not
   transferred into the program's memory space.  Instead, the file is
   "mapped" into an area of the caller's data space (involving no
   actual data transfer) and demand-paged into real memory, directly
   from its disk file, as accessed by the program.  As long as any such
   page remains pure, it never needs to be swapped out to disk, and can
   always be swapped in from its original location on disk.  If a page
   becomes dirty, it will have separate swap space allocated for it on
   disk and the page will be re-mapped to that space.  [This technique
   is often used for the initialized data portion of executing
   programs].

   Therefore, "vread" produces the appearance of reading from a file
   into memory, but no data actually transferred (in a memory managed
   system), and the system is afforded the opportunity to optimize by
   sharing the data among all processes accessing the file.  From the
   program's point of view, this operation is indistinguishable from an
   actual data transfer.  In non-memory-managed versions of UNIX,
   "vread" is implemented as a true data transfer.  Therefore, "vread"
   calls are portable between memory-managed and non-memory-managed
   systems.

   Since the system decides the address at which the space will be
   allocated, specific memory management requirements (such as page
   size and alignment) are hidden from the caller and are therefore of
   no concern to a program using this facility.

   In a memory managed system, use of "vread" can provide a significant
   optimization when large portions of files must be available in their
   entirety, but are sparsely and/or randomly accessed (such as the
   pseudo-code for an interpreter), and when it is desirable to share
   large, read-only files.

RETURN VALUE

   Same as read(ba_os).

ERRORS

   Same as read(ba_os).

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

For interpreters to take full advantage of this facility, they would
have to interpret their p-code "as is" as it sits on disk.  If they
modify the code, much of the advantage would be lost.

I'd be interested in hearing your comments and suggestions regarding
this idea; alternative ideas to solve this problem, ways other OSs have
dealt with it, implementation problems, or gross oversights.  What
would you think of a "read only" option for this function (a fourth
argument?), where the data would be mapped as read only. This would
cause a trap if the buffer is stored into.
-- 

Bob Alexander	   ISC Systems Corp.  Spokane, WA  (509)927-5445
		   UUCP: ihnp4!tektronix!reed!iscuva!boba