From: abuhr@owlnet.rice.edu (Aaron M. Buhr)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: CBM mention on 12/11/92 Computer Chronicles
Date: 12 Jan 93 22:05:40 GMT
Organization: Rice University

In article <jprad.726772078@faatcrl> jprad@faatcrl.faa.gov (Jack Radigan) writes:
>  That is all well and good, but I wasn't refering to, nor was I intimating
>that the programmer should supply VM.  If that's how you associated a program
>that was constructed with an overlay map as, then you're completely mistaken.
>
>  And, I still stand behind my assertion that for most applications that are
>run under a personal computing environment, ie. a *single* user environment,
>an overlayed program is easily fabricated, if it was designed as such from the
>beginning of the project.
>
>  In that light, when compared to the OS managing memory services, a VM system
>probably will not be able to match the memory utilization as efficiently since
>the OS cannot "know" as much about the program is it's designers did.


     The inherent limitation to any overlaying system in a multitasking
environment is that there is no practical way for applications to tell each
other how much memory they need, and how much memory they can actually use.
For example, say you have 1 MB of RAM to allocate between ten concurrent
programs.  Assuming each program has between 400K and 1 MB of code, and
they use overlays so that only 100K of each is actually in memory at a
time.  That means that whenever the currently active program wants to 
access something outside that 100K of overlay space, no matter what the
other programs are doing, it has to stay within that 100K space allocated
to it.  It can't tell the other applications "hey, you're not being used
much at the moment, free up some memory for me."  In contrast, a VM system
will swap out the code not being currently used by the other programs,
maintaining just the minimal amount necessary for their current code loop
or blocked procedure, and use the free memory for the more memory-intensive
process.
     
     With an overlay-only system, what would happen in a case like this is
that the more heavily used programs will swap a lot, loading 100K overlays
frequently, while a VM system would swap out most of the less heavily used
programs and let the more active programs use that memory, thus avoiding
overlay swapping and making the whole system faster.  Unless all concurrent
programs are making equal use of their allocated memory, the overlay system
is less efficient.  The VM system naturally ensures that the available
memory is used to its fullest, most efficient extent.

    Also, overlays are at best a poor solution to resolving concurrent
programs' demands for memory for data (as opposed to code).  By data
overlays I mean only reading in and processing definite-size chunks of data,
rather than operating on the whole data set.  The same problem exists here
as it did with memory for code, except that it is much magnified by the 
greater extent that data size varies as opposed to code size.  Since data 
memory requirements vary much more widely, it is much less likely that all
concurrent programs will be making equal use of their allocated memory.
Here again, VM ensures that the available memory is allocated to programs so
as to make the most efficient use of that memory.

    And there is the additional problem (again, in a multitasking
environment) of determining the proper overlay size.  If it is too small,
you end up swapping overlays very frequently.  If it is too large, at any
given time you may not have enough memory available (the size of that
overlay, whether code or data) to run the program, thus unnecessarily
restricting that program's use.  VM systems can dynamically vary the amount
of memory each program is using in order to make room for for new programs
to run, until you run out of swap space.

     For single programs, overlays are indeed the most efficient solution,
since they can organize themselves best in order to avoid swapping their
own code or data unnecessarily by grouping frequently used code or data 
together.  However, there is no practical way for the program to know
whether other programs could make better use of that memory, or that those
same other programs could grant it their memory.  And the overlay size will
likely either cause unnecessary swapping, force you to shut down other
programs, or fail to work at all on low-real-memory systems.


Aaron Buhr
abuhr@owlnet.rice.edu