September 96 - THE OPENDOC ROAD: Facilitating Part Editor Unloading
The OpenDoc Road: Facilitating Part Editor Unloading
Vincent Lo
In the traditional application model, the code for an application typically
remains loaded until the process quits. In OpenDoc, starting with version
1.0.1, a part editor is loaded when it's needed during a session and unloaded
when it's not. As a result, valuable memory space can be reclaimed and reused
by other part editors.
Even though part editor unloading is mostly transparent to part editors, there
are a few things a part editor should do to ensure the success of this scheme.
I'll describe these things after giving you a closer look at how part editor
unloading works. Pay careful attention, because the crash you prevent may be
your own.
The part editor unloading mechanism is enabled by facilities provided by
SOMobjects
(TM) for Mac OS (the Apple implementation for the
Macintosh of the IBM SOM
(TM) technology). The basis of part editor
unloading is a reference-counting system that enables OpenDoc to keep track of
which part objects are in use. I'll explain reference counting and then give
the gory details of how part libraries are unloaded, which differs for static
and dynamic classes.
Every persistent object (part, frame, link, and so on) in OpenDoc is given a
reference count by the draft that creates it. When the object is first created
or acquired, its reference count is initialized to 1. Whenever the object is
acquired after that (through either the draft's or the object's Acquire
method), its reference count is incremented by 1. Whenever the object is
released (by a call to the object's Release method), its reference count is
decremented by 1.
When all clients have released their references to an object, the reference
count of the object is 0, and at this point the draft can delete the object to
regain the memory it occupies. However, deletion may not be immediate when the
object's reference count drops to 0. In actuality, object deletion is deferred
until the purge mechanism of the draft is triggered. Typically, a purge is
initiated by the storage system (for example, during a save operation) or by
the document shell (such as when the document shell realizes that memory is
running low).
In response to a purge request, the draft deletes all the persistent objects
and storage units that aren't in use -- that is, objects whose reference count
is 0. When all the part objects belonging to a certain part editor are deleted,
SOM calls the Code Fragment Manager (CFM) to unload the part editor library.
The CFM calls the CFMTerminate routine of the part editor library, and both the
code and data sections of the library are destroyed. Some details of how the
library is unloaded depend on the kind of SOM class it contains -- either
static or dynamic.
Objects created using new className and SOM kernel services (somNewObject,
somNewClassReference, and SOMobject::somGetClass) are static class objects.
Most (if not all) objects created by a part editor fall into this category. A
static class is unloaded when the code that created the static class object is
unloaded. Therefore, when a part editor is unloaded, all static classes in the
same library are unloaded as well. Other interdependent libraries may also be
unloaded; there will be more on this later.
Objects created using the runtime name or ID class-lookup services of SOM (for
example, SOMClassMgr::somFindClass, somNewObjectByName, or
somGetDynamicClassReference) are dynamic class objects. OpenDoc parts are
dynamic class objects, since they're created by name. Extension objects are
also dynamic because ODExtension is implemented as a dynamic class; subclasses
of ODExtension inherit its dynamic property as long as they call the parent's
InitExtension method. Other OpenDoc classes will be converted to dynamic
classes as the need arises; check the notes accompanying future OpenDoc
releases for a listing of these.
A dynamic class guarantees that its code and the code for its inherited classes
won't be unloaded until the last object of the class is deleted. When the last
instance of a part class is deleted, SOM unloads the CFM library containing the
part class.
Every persistent object must have a correct reference count for the part editor
unloading mechanism to work. If a part object has a reference count that's
higher than the correct count, the object will remain valid throughout the
session even though it's no longer being used. This object will keep its
associated part editor library from being unloaded until the process quits.
Conversely, if an object has a reference count that errs on the low side, the
object may be deleted, causing its library to be unloaded. Referencing an
invalid object pointer usually results in a crash.
The best way to avoid reference-count errors is to familiarize yourself with
OpenDoc persistent objects and follow the recipes outlined in the OpenDoc
Programmer's Guide for the Mac OS. Be sure to pay special attention to the
following potential trouble spots.
Avoid
self-referencing. If a part object keeps a reference to itself, its reference
count will be at least 1 and its part editor library won't be unloaded until
the session ends. Since a reference to the part is passed in as an argument in
every ODPart method, a part shouldn't need to store a reference to itself.
Break
circular references between parts and frames. Each display frame has a
reference to its part (after the part has been internalized). Even though a
part isn't required to keep a reference to its display frames, most parts do so
for convenience. This creates a circular reference between a part and its
display frames, so the reference count alone won't indicate when deleting a
part is appropriate. The situation becomes more complicated when the part has
embedded frames and also keeps references to them.
To break these circular references, OpenDoc offers the Close and Remove
protocols.
- The Close protocol is triggered when a containing part decides to get rid
of its runtime-embedded frame objects. The containing part calls the embedded
frame's Close method. The frame first calls its part's DisplayFrameClosed
method, which should release its reference to the display frame and close its
embedded frames (if any) before releasing its reference to the part.
- The Remove protocol works similarly to the Close protocol. However, the
protocol is triggered when a containing part decides to remove its embedded
frames from both runtime storage and persistent storage. The Remove protocol is
propagated through the ODPart::DisplayFrameRemoved and ODFrame::Remove
methods.
Unregister
frames and parts when idle time is no longer needed. When a part registers its
frame with the OpenDoc dispatcher for idle time, the dispatcher retains a
reference to the frame. Until the part editor unregisters the frame object from
the dispatcher, the object will remain resident in memory with a reference
count greater than 0. This will prevent the object from being deleted and its
library from being unloaded. The part editor should unregister the frame when
the Remove or Close protocol is triggered.
On rare occasions, a part may have a display frame that's not in the frame
hierarchy originated from the root frame. For example, a part may have some
frames stored for the View in Window command. Don't internalize those frames
and register them for idle time until the frames are actually used.
A part may also register itself with the OpenDoc dispatcher for idle time. As
in the case of registered frames, the dispatcher retains a reference to the
part object. To ensure that the object is deleted and that its library is
unloaded at the earliest possible time, the part editor must unregister itself
from the dispatcher as soon as idle time is no longer needed. This usually
occurs when all the part's display frames have been closed or removed.
Watch
extensions for reference-counting problems. OpenDoc's extension mechanism
enables separate parts in a document to communicate with each other directly.
By creating an associated extension object, a part editor can extend its part
interface to satisfy special needs. To enable efficient communication, the
extension object maintains a reference to the part object that created it; the
part typically keeps a reference to the extension so that it can give out the
same extension object again if it's requested.
In general, an extension object is released before its creator, thus preventing
any reference-counting problem for the part. But if the reference count of the
extension object isn't maintained correctly, or if the client of the extension
object refuses to release it, the part object can detach the extension object
from itself by calling ODExtension::BaseRemoved. A well-behaved extension
object should then report errors to clients when it's being accessed. An even
better idea is to avoid using the base removal mechanism and instead to define
the scope and lifespan of an extension.
When a part editor is unloaded, SOM unloads the CFM library associated with the
part editor. Moreover, if there's another library in the same library closure
as the part editor, the CFM will unload it if it doesn't belong to another
library closure. (A library closure is a group of shared libraries whose
interdependencies cause them to be loaded together by the CFM.) This means that
code other than the part editor residing in the same CFM library closure is
unloaded as well. If the developer hasn't foreseen this possibility, it can
lead to unfortunate consequences.
Let's consider a typical example. A part editor creates a SOM object from a
static class that resides in the same library closure as the part editor. The
part editor then installs the object in a name space so that others can access
it. If this object doesn't hold a reference to the part, the part may be
deleted (and its library closure unloaded) when the object reference is still
in the name space. The next time this object is used, a crash will likely occur
because the code associated with the object has been unloaded with the part
editor.
To prevent this from happening, you should ensure that no class whose code
resides in the same library closure as the part editor outlives the part
itself. If an object must outlive the part that creates it, the object should
be created dynamically. OpenDoc provides a utility function, ODNewObject, to
create objects by name. The code in Listing 1 illustrates how a dynamic object
is created with ODNewObject.
Listing 1. Creating a dynamic object with ODNewObject
#include "ODNewObj.h"
ODObjectNameSpace* objNameSpace =
(ODObjectNameSpace*) nameSpMgr->CreateNameSpace
(ev, kOSAScriptingTool, kODNULL, 1, kODNSDataTypeODObject);
Sample_ScriptRunnerAgent* agent =
(Sample_ScriptRunnerAgent*) ODNewObject
("Sample::ScriptRunnerAgent");
objNameSpace->Register(ev, kOSAScriptingTool, agent);
As
mentioned earlier, parts and extensions are dynamic objects and thus don't
require ODNewObject. ODNewObject is used mainly on SOM classes that a part
developer has created.
Once a class has been accessed dynamically, the class remains dynamic until the
process exits or the use count of the class maintained by SOM goes to 0. Until
then, all object references created for the class are considered dynamic by SOM.
Part editor unloading in OpenDoc is a great scheme for managing memory
efficiently. But its success depends on the cooperation of each and every part
editor. If you keep in mind the gotchas detailed in this column, your part
editor will avoid the pitfalls and reap the benefits of wise resource use.
VINCENT LO is Apple's technical lead for OpenDoc. In his leisure time, he loves
to travel and sample exotic food. Living in Hong Kong for many years convinced
him that no food can scare him, but he'll continue to trot the globe to seek
out gustatory challenges.
Thanks to Dave Bice, Erik Eidt, and Troy Gaul for reviewing this column.
