April 90 - DEMYSTIFYING THE GS/OS CACHE
DEMYSTIFYING THE GS/OS CACHE
MATT DEATHERAGE
GS/OS has given Apple IIgs users an important capability: caching. To the newly
initiated, the mysteries of the GS/OS cache may still seem profound. This article
clarifies the basics of the caching algorithm and offers useful pointers for working
safely and efficiently.
In the past couple of years, the Apple IIgs system software has grown by leaps and
bounds. With the introduction of thousands of new features and capabilities, one very
important one often goes unnoticed. GS/OS is the first Apple II operating system of any
kind to provide a comprehensive caching implementation.
Although the cache is an important part of GS/OS, its purpose and nature are
sometimes misunderstood. Some people create huge caches in the hope that peripherals
will start behaving like RAM disks. Others set the cache size to zero because they think
it's wasting time and memory. Some developers mistakenly believe their program has
absolute control over caching, which is only true if they're writing device drivers.
This article reaches into the murky depths of your IIgs's memory and allows you to
examine the cache in the light you would normally use, say, to read develop by.
CACHE FUNDAMENTALS
Let's start at the beginning, with the basics. What's a cache? How is it managed? How
big is it? How does the GS/OS cache differ from that of the Macintosh? Read on.
WHAT'S A CACHE?
A cache is a part of memory in which the operating system can keep a spare copy of
information read from and written to a device, in an attempt to decrease disk access
time.
Many people use RAM disks to decrease disk access time. Because the operating system
doesn't actually have to physically manipulate any media to access information on a
RAM disk, the information is saved and retrieved at a very nice clip, exceeded only by
the speed at which the operating system can read information already in main memory.
In a caching algorithm, that is exactly what happens.
When information is read from a device, the operating system reads from the physical
media and returns the information to the caller who asked for it. Additionally, the
operating system keeps a spare copy of the information in the cache. The next time a
caller requests information, the operating system first looks in the cache to see if it
already has it from a previous media access. If it's there, the operating system simply
moves the data into the caller's buffer, completing the call without having to actually
read anything from disk.
Information to be written can also be cached. The operating system writes the
information to the disk and also writes it to the cache. This method, called a
write-through cache, ensures that the information in the cache is never more recent
than the information on the disk. GS/OS uses a write- through cache except in one
special situation--during a write-deferral session.
THE CACHE MANAGER AND WHAT IT CACHES
In GS/OS, several distinct managers handle different parts of the operating system or
environment. Many of these managers (the Loader and the Device Manager, for
example) are familiar to application and driver authors. Another, more obscure
manager takes care of the cache; plainly enough, it's called the Cache Manager. The
Cache Manager handles the storage of the cache and all requests involving it.
The GS/OS Cache Manager only caches one thing: blocks. Blocks are what both generated
and loaded drivers read from block devices. They can be traditional ProDOS-sized
512-byte blocks from traditional ProDOS devices; they can be 512-byte blocks from
nontraditional ProDOS devices, such as network volumes or nondisk devices; or they
can be odd-sized blocks from odd peripherals. If you had a GS/OS loaded driver to read
981-byte blocks from a 20-gigahertz, 35-terabyte RAM disk hooked to your Apple
IIgs through a slot-based card, GS/OS could cache those blocks. (Whether or not any
file system translators in the system could use the device is another story.) The Cache
Manager does not cache anything having to do with printers, modems, or other
character devices.
THE SIZE OF THE CACHE
The size of the cache is determined by a battery RAM (BRAM) parameter. When the
Cache Manager is initialized as part of the GS/OS boot process, it retrieves this value
from the battery backed-up RAM and adjusts so that the given value is taken as the
maximum size to which the cache can grow. The BRAM parameter is currently
number $81 and represents the cache size in 32K increments (a value of 2 would
indicate 64K). You should know that the location and interpretation of the cache size
parameter are not guaranteed at this point, and relying on the location or
interpretation of the parameter might get you into trouble. When they are guaranteed,
Apple II Developer Technical Support will release a Technical Note detailing this point,
or the GS/OS Reference will be revised to document it.
The size of the cache is not an exact number but an exact maximum, and it is that only
when nonzero. If the user has set the cache size to nonzero, that value (which will
always be an increment of 32K) is the maximum cache size. If the user has set the
cache size to zero, GS/OS allocates a 16K cache for system purposes--so that system
components such as file system translators (FSTs) and drivers (both generated and
loaded) can take advantage of the speed increase the cache provides. There is no way to
completely turn off caching under GS/OS.
When the cache is initialized, it is empty and has zero size. As blocks are added to it, it
grows as necessary to accommodate the increased use until the maximum size is
reached. If no one ever asks for blocks to be cached, the cache remains empty and
occupies no memory.
WHAT HAPPENS WHEN THE CACHE IS FULL
Having a maximum cache size implies that there can be a problem -- what happens
when nothing else can be written to the cache because there is no room in cache
memory for more information? How does GS/OS behave when there's no room in the
Cache Inn?
The operating system, through the cache algorithm, has a few options for handling the
possibility that the cache will be full. The most obvious option is for the algorithm to
shrug its bit-encoded shoulders and say, "Well, the cache is full, so nothing else will
be written to it." Information that comes knocking at the door thereafter is written to
disk only and read from disk each time it's needed.
Most caching algorithms, including the one used by GS/OS, are a little bolder. They
attempt to identify which blocks in the cache have actually been used and to keep those
blocks in the cache, simultaneously removing from the cache the blocks that have not