The Joy of Reference Counting
David Chappell - August 1997
One of the standard parts of object technology is the notion of
an object's lifecycle, the key aspects of which are creation and
deletion. To create a new instance of some class, for example, C++
and Java programmers can use the new operator, while a COM programmer
might call CoCreateInstance to create a new COM object. While it
exists, this object instance can be accessed by one or more clients,
and some memory is typically allocated for its state.
Figuring out how to get rid of an object instance when it's no longer
needed is a bit more challenging. One option is to assume omniscience
on the part of the programmer: just as she knows when to create
a new object, she also knows when to destroy it. This is essentially
the strategy used in C++, where an object allocated with new can
be destroyed with delete.
In Java, however, a client can create an object, use it for awhile,
then just forget about it. Objects with no active clients are eventually
deleted by Java's garbage collector, the existence of which frees
programmers from worrying about explicitly deleting objects. Automatic
garbage collection is a very nice thing to have, since it's easy
to forget to delete an object when you're done using it.
Deleting COM Objects
Unlike C++, COM doesn't provide an explicit delete operation. COM
also doesn't necessarily assume the presence of an automatic garbage
collector. Instead, COM relies on reference counting to determine
when an object can safely delete itself. To accomplish this, each
COM object maintains a count of how many clients hold references
to its interfaces. Every time the object hands out a pointer to
one of its interfaces, it adds one to that reference count. In some
cases, when a client acquires an interface pointer to an object
from a source other than the object itself, that client must call
the object's AddRef method, which also causes the object to increment
its reference count by one. Whenever a client is finished using
an interface pointer, it calls Release on that pointer, and the
object subtracts one from the reference count. When all clients
have finished using all of an object's interfaces, i.e., when the
reference count falls to zero, the object typically commits suicide,
freeing any resources it has been consuming.
It doesn't take a whole lot of thought to realize that requiring
software developers to correctly call AddRef and Release all the
time might lead to problems. Some developers (not readers of this
magazine, of course, but some other developers) might forget to
call Addref when they should, or they might call Release too often
or not often enough. Errors like these will result in odd behavior,
such as objects that die prematurely or wear out their welcome by
hanging around after all of their clients are gone. Yet the original
view of C++ COM programming assumed just this kind of correctness
on the part of COM programmers. The predictable result was that,
sometimes, things didn't work as expected.
COM Reference Counting Today
The situation is different today. For one thing, COM is supported
by lots of different languages, including Visual Basic, Java, and
many more. In most of these cases, reference counting is hidden
from the programmer-he never needs to call AddRef or Release. Instead,
the language runtime takes care of the work required to make reference
counting work correctly.
For example, in Microsoft's implementation of the Java Virtual Machine,
a Java client can treat an external COM object as if it were a Java
object. When the client is done using the object, it can forget
about it, just as with any other Java object. As always, the Java
garbage collector notices the now-unused object and proceeds to
delete it. If the garbage collector in Microsoft's Java VM determines
that the object in question is a COM object, it simply calls Release
on the object. Reference counting is still used to control the lifetime
of every COM object, but the Java programmer is freed from the responsibility
of worrying about it-it's taken care of automatically.
Even C++ programmers can now avoid this potentially error-prone
task. Microsoft's Visual C++ 5.0 can automatically generate smart
pointer classes that know how to do reference counting correctly.
While many C++ COM programmers have long used this technique to
simplify their lives, having the classes produced automatically
is quite handy. Reference counting remains the underlying mechanism
used for controlling the lifetime of COM objects, but it no longer
need be the programmer's concern.
Reference Counting for Remote Objects
Hiding reference counting from programmers is unquestionably a good
thing, but it doesn't affect another potential problem: how can
reference counting be done effectively across a network? Distributed
COM (DCOM) faces exactly this problem, since COM uses reference
counting to control the lifetimes of both local and remote objects.
There are two main thing to worry about with remote reference counting.
The first concern is efficiency: if clients call AddRef and Release
frequently (and they typically do), one could imagine that lots
of network traffic might be generated just keeping each remote object's
reference count up to date. The second problem is making sure that
unexpected client failures (remember, we're talking about clients
running Windows here) don't result in garbage objects that hang
DCOM's designers handled the first problem by realizing that all
an object needs to avoid premature self-immolation is a non-zero
reference count. Whether the count's value is one or one hundred,
the object won't go away. This means that a large number of the
AddRef and Release calls clients make on remote objects can be handled
locally on the client's system-as long as an object thinks it has
at least one client, it won't go away. In DCOM, most calls to Addref
and Release go no farther than the client proxy (DCOM's term for
a client stub)-they aren't actually sent across the network. Only
when the last Release occurs is a message actually sent to the remote
object. While this means that the object's reference count won't
always match its actual number of clients, who cares? The result
is the same-objects die only when they're supposed to-and a good
deal of unnecessary network traffic is avoided.
The second problem is a little harder. When a client dies unexpectedly,
it will never be able to call Release on the objects to which it
holds references. Without some way for the remote object to learn
about its client's untimely demise, it will never be able to delete
itself. If this happens a lot (as it will in a network of any reasonable
size), servers will grow without bound, and eventually need to be
shut down and restarted to free those resources. This is an unattractive
solution, one that's bound to annoy existing clients that are using
There's a standard way for an object to learn about its client's
death: the client can periodically send the object's server a packet,
reassuring the object that its client is still alive. If enough
time passes without the arrival of one of these keepalive packets,
the server can assume the client is dead and take the appropriate
action. This is exactly what DCOM does. Every two minutes a ping
packet is sent to the server; if no such packets arrive for three
ping periods-six minutes-the server assumes the client is dead and
calls Release as needed.
The prospect of every client sending a ping packet to every object
it holds a reference to on every server is chilling. If done naively,
it's easy to imagine all of a network's bandwidth being eaten up
by pinging. Fortunately, DCOM's designers didn't choose to do things
this way. Instead, the DCOM infrastructure automatically creates
ping sets consisting of every client/referenced object combination
on each pair of machines. The entire ping set is then kept alive
with a single packet sent every two minutes between those two machines.
One packet every two minutes between each pair of machines, while
not exactly free, is much better than blindly sending a separate
ping packet for each client/object pair.
Complaining About Problems vs. Solving Them
The OMG has been fiercely critical of DCOM's pinging approach to
distributed garbage collection, claiming that it will never scale.
But the CORBA standards deal with this problem by pretending it
doesn't exist-they don't define a solution. As a result, different
CORBA-based products do different things. Some essentially require
servers to be periodically shut down and restarted to avoid infinite
growth due to garbage objects maintained for crashed clients. Others
rely on some kind of pinging, whether based on TCP keepalives or
an ORB-specific mechanism. The key point is that these allegedly
standard products solve this crucial problem in different ways,
which doesn't bode well for interoperability among them.
Reference counting isn't without cost. But for true component architectures,
where an all-knowing component that knows when to delete everything
can't exist, it's the only viable solution to the problem of deleting
objects when they're no longer needed (in fact, even the apparently
dead OpenDoc relied on reference counting). And when hidden beneath
language-appropriate mechanisms, reference counting can be simple-programmers
don't even need to know it's there.
design and development by kmcreative.
KMCREATIVE is a Silicon Valley based graphic design firm specializing
in corporate collateral, web design, web development, identity,
medical illustration and product illustration.