MORE INFORMATION
The following article was originally posted on the Internet newsgroup
COMP.SYS.MAC.APPS. This article discusses how the Power Macintosh uses
virtual memory. It also discusses how Microsoft Applications make use of
virtual memory and how they use shared libraries.
USING VIRTUAL MEMORY WITH THE POWER MACINTOSH
The Power Macintosh runtime architecture was designed with virtual memory
in mind; therefore, when you use a Power Macintosh, you should usually have
virtual memory turned on.
NOTE: Apple shipped the Power Macintosh with the Virtual Memory option turned off by default with System 7.1.2. With System 7.5x, the Virtual Memory option is turned on by default.
How Applications Are Stored and Loaded on a 68K (Non-Power) Macintosh
On a 68K Macintosh, you give every application a partition size. This
partition is used to hold the application's stack and heap. The heap is
used to hold the following:
- Memory that is dynamically allocated by the application (that is, to
hold the contents of the cells in a spreadsheet, or the text in a Word
document).
- Application resources (icons, dialogs, alerts, some strings).
- Application code (note that code is actually just another resource,
and Word and Microsoft Excel, for example, each have several hundred
code resources).
Breaking up the application's code into resources means that the
application's code can be loaded into memory in small chunks, and it's
loaded only when needed. For example, when you start the application, only
a very few code resources get loaded. Then, when functions are called that
are located in segments that are not yet loaded into memory, those segments
get loaded. When segments are not used, they can be kicked out of memory to
make room for other code segments. What this means is that the partition
can be considerably smaller than the total size of the application's code.
NOTE: The above is true for all Macintosh 68K applications, not just
Microsoft applications.
Microsoft applications go one step further and use technology developed
especially for our Macintosh applications. This technology allows a
Microsoft application to swap out more code that it would normally be able
to. Basically, most applications cannot swap out any segment that contains
code that's on the current call chain, because the code returning to that
segment would crash if the code was unloaded; the Microsoft swapper unloads
the segments, and fixes up the stack to point to code that reloads the
segment. The result of this is that we can run in even smaller partitions
than we would be able to otherwise.
How Applications Are Stored and Loaded on a Power Macintosh
On the Power Macintosh, things are quite a bit different. Power Macintosh
code is not segmented into resources. Instead, the code sits in one large
chunk (called a "fragment") in the application's data fork. (Macintosh
files have two pieces: a data fork and a resource fork.)
Note that this configuration is what makes fat binaries possible: in a fat
binary, all the 68K code sits in code segments in the resource fork, and
the Power Macintosh code sits in the data fork. A 68K Macintosh knows only
about the resource fork, but a Power Macintosh knows to look in the data
fork (there's a special resource that says to look in the data fork that
only the Power Macintosh loader knows about).
How Applications Are Loaded to Memory on a Power Macintosh
So the question is, with all the code sitting in one big chunk, how is the
system going to load it?
When Virtual Memory Is Off:
If virtual memory is off, the system has no choice but to load the ENTIRE
chunk of code that's in the data fork [in the case of Microsoft Excel, this
means about 7 megabytes (MB) of code] into memory. That's right, no code
resources, no fragmentation, no swapping--the whole thing goes into memory.
To do this, the system increases the partition size you've allocated by the
full amount of the code size.
Why does the system add the full amount of the code (after all, on the 68K
Macintosh, the code goes in the partition anyway)? The system has to add
the full amount of code for the following two reasons:
- The code doesn't go in the heap with the other resources, it goes in
a separate area of the partition.
- On a Power Macintosh, you would typically need a bigger partition
because stack frames are larger, but since there's no code, things
roughly balance out.
So, if virtual memory is off, the system looks at your partition size
(which is used for stack and heap, but not code), adds the complete
size of the application code, and uses that for a new partition.
When Virtual Memory Is On:
When virtual memory is on, however, the system does not have to load
all the application's code at once. Instead, it "demand pages" the
code from the disk using a technique called "file mapping." What this
means is that when code is needed, it is brought in from the disk,
and it can also be kicked out of memory to make room when needed.
While there is no explicit segmentation of the code into resources,
the virtual memory system divides a file into 4K chunks, and brings
in and kicks out those chunks as needed. So, the system adds nothing
to the partition size, and then it is smart about loading in code as
needed. You might even say that when virtual memory is on, the system
can pretty much do what it does on a 68K machine: that is, it can
bring in code in chunks, and kick them out to make room for other
chunks.
POWER MACINTOSH SHARED LIBRARIES
On a 68K Macintosh, it's very difficult to share code between applications.
What this means is that if two applications want to share code in any non-
trivial way, they typically must each include a copy of the code. That
means that two copies of the code sit on your hard disk (and in memory if
the programs are running).
The Power Macintosh makes things a lot better by adding shared libraries.
Applications can share code by putting this code in a shared library. A
shared library is loaded into memory only once, no matter how many
applications are using it. Another benefit of a shared library is that
if there is a bug in it, it can be replaced without replacing the entire
application.
Microsoft applications take full advantage of this new feature of the Power
Macintosh. We put the pieces of code that our applications may share in
shared libraries. These libraries include the following:
- A dialog manager that is shared between Microsoft Excel and Word
- A toolbar button editor that is shared between Word, Microsoft Excel,
PowerPoint, and Microsoft Project
- Support for Microsoft Mail in Word, Excel, PowerPoint, and Project,
- OLE
- The Visual Basic, Applications Edition, macro language
Where the Libraries Are Loaded in Memory
If virtual memory is on, the libraries are "demand paged" as needed (the
same way that applications are loaded).
If virtual memory is off, however, the system needs to load all the code in
all these libraries when you start up the application. And, because these
are shared libraries, potentially used by other applications, these can't
go in an application partition; they have to go in the system heap. In the
case of Microsoft Excel there are about 6MB of code in these libraries.
Note that when you load other applications that use these libraries, they
don't get loaded again (because they're shared).