home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.11 / text0054.txt < prev    next >
Encoding:
Internet Message Format  |  1987-07-18  |  4.5 KB
  1. From: boba@iscuva.ISCS.COM (Bob Alexander)
  2.  
  3. Modern, memory managed operating systems (like UNIX) have addressed
  4. quite nicely certain special requirements of executable files.  In
  5. particular (1) the file (text and data) need not be loaded into memory
  6. in its entirety to begin executing, and (2) the pages can be shared
  7. among processes that are executing them (both on disk and in memory).
  8.  
  9. As far as I know, those capabilities are not made available to
  10. interpreters for their pseudo-code and data, even though they would be
  11. equally as applicable as they are to "real" programs.  If 15 users are
  12. running a program written in an interpretive language, the interpreter
  13. code is shared, but the p-code exists separately for each user.  This
  14. results in a major disadvantage in the use of interpretive languages to
  15. produce production programs.  Interpretive systems are in quite wide
  16. use today (e.g. shells, SQLs, (((Lisp))), Icon, etc., etc., [even
  17. BASIC]), and as processor speeds increase, use of interpreters will
  18. likely continue to grow.
  19.  
  20. There are a few ways of working this problem with existing UNIX
  21. facilities, but the ones I've come up with so far are kluges.  My
  22. reason for posting to this newsgroup is to get your reaction to a
  23. possible new UNIX facility for this purpose.  I'll express my
  24. suggestion in SVID format, sort of:
  25.  
  26. ------------------------------
  27.  
  28. NAME
  29.  
  30.    vread -- read from a file into memory [but not really, maybe].
  31.  
  32. SYNOPSIS
  33.  
  34.    int vread(fildes, bufptr, nbyte)
  35.    int fildes;
  36.    char **bufptr;
  37.    unsigned nbyte;
  38.  
  39. DESCRIPTION
  40.  
  41.    The function "vread" attempts to read "nbyte" bytes from the file
  42.    associated with "fildes" into an allocated buffer whose address is
  43.    returned in "bufptr".  This function is similar to read(ba_os)
  44.    [read(ba_os) is SVIDese for read(2)] except for its implications
  45.    concerning virtual memory and that it allocates a buffer rather than
  46.    being given one.
  47.  
  48.    In a memory managed system, the contents of the file are not
  49.    transferred into the program's memory space.  Instead, the file is
  50.    "mapped" into an area of the caller's data space (involving no
  51.    actual data transfer) and demand-paged into real memory, directly
  52.    from its disk file, as accessed by the program.  As long as any such
  53.    page remains pure, it never needs to be swapped out to disk, and can
  54.    always be swapped in from its original location on disk.  If a page
  55.    becomes dirty, it will have separate swap space allocated for it on
  56.    disk and the page will be re-mapped to that space.  [This technique
  57.    is often used for the initialized data portion of executing
  58.    programs].
  59.  
  60.    Therefore, "vread" produces the appearance of reading from a file
  61.    into memory, but no data actually transferred (in a memory managed
  62.    system), and the system is afforded the opportunity to optimize by
  63.    sharing the data among all processes accessing the file.  From the
  64.    program's point of view, this operation is indistinguishable from an
  65.    actual data transfer.  In non-memory-managed versions of UNIX,
  66.    "vread" is implemented as a true data transfer.  Therefore, "vread"
  67.    calls are portable between memory-managed and non-memory-managed
  68.    systems.
  69.  
  70.    Since the system decides the address at which the space will be
  71.    allocated, specific memory management requirements (such as page
  72.    size and alignment) are hidden from the caller and are therefore of
  73.    no concern to a program using this facility.
  74.  
  75.    In a memory managed system, use of "vread" can provide a significant
  76.    optimization when large portions of files must be available in their
  77.    entirety, but are sparsely and/or randomly accessed (such as the
  78.    pseudo-code for an interpreter), and when it is desirable to share
  79.    large, read-only files.
  80.  
  81. RETURN VALUE
  82.  
  83.    Same as read(ba_os).
  84.  
  85. ERRORS
  86.  
  87.    Same as read(ba_os).
  88.  
  89. -------------------------------------
  90.  
  91. For interpreters to take full advantage of this facility, they would
  92. have to interpret their p-code "as is" as it sits on disk.  If they
  93. modify the code, much of the advantage would be lost.
  94.  
  95. I'd be interested in hearing your comments and suggestions regarding
  96. this idea; alternative ideas to solve this problem, ways other OSs have
  97. dealt with it, implementation problems, or gross oversights.  What
  98. would you think of a "read only" option for this function (a fourth
  99. argument?), where the data would be mapped as read only (i.e.
  100. protected).
  101. -- 
  102.  
  103. Bob Alexander       ISC Systems Corp.  Spokane, WA  (509)927-5445
  104.            UUCP: ihnp4!tektronix!reed!iscuva!boba
  105.  
  106.  
  107.  
  108. Volume-Number: Volume 11, Number 55
  109.  
  110.