Distributed Garbage Colle

tion for
Wide Area Repli ated Memory
Alfonso San hez Luis Veiga Paulo Ferreira
INESC/IST,
o
Rua Alves Redol N 9,
Lisboa 1000-029, Portugal
falfonso.san hez, luis.veiga, paulo.ferreiragines .pt

Abstra t tributed appli ations. The reason is that graphs

of rea hability are large, widely distributed and fre-
It is well known that distributed systems pose se- quently modied through assignment operations ex-
rious diÆ ulties on erning memory management: e uted by appli ations. In addition, data repli ated
when done manually, it leads to memory leaks and in many pro esses is not ne essarily oherent mak-
dangling referen es ausing appli ations to fail. We ing manual memory management mu h harder. For
address this problem by presenting a distributed these reasons it is impossible to do manual memory
garbage olle tion (DGC) algorithm for distributed management without generating dangling referen es
systems supporting repli ated data over wide area and/or memory leaks.
networks. Automati memory management, also known as
Current DGC algorithms are not well suited for Garbage Colle tion (GC), is the single realisti op-
su h systems be ause either (i) they do not onsider tion whi h is able to maintain referential integrity
the existen e of repli ation, or (ii) they impose se- (i.e. no dangling referen es or memory leaks) in
vere onstraints on s alability by requiring ausal Wide Area Repli ated Memory (WARM) systems.
delivery to be provided by the underlying ommu- As a result, program reliability and programmer
ni ation layer. produ tivity are learly improved.
Our algorithm solves these problems by (i) adapt-
ing lassi al referen e- ounting DGC algorithms 1.1 Short omings of Current Solutions
that were on eived for non-repli ated systems (e.g.
indire t referen e- ounting, SSP hains, et .), and Current DGC algorithms [1, 15℄ are not well suited
(ii) improving our previous algorithm for repli ated for WARM systems based on data-shipping be ause
systems (i.e. Lar hant). of the following drawba ks: either (i) they do not
The result is a DGC algorithm that, besides be- onsider the existen e of repli ation, or (ii) they im-
ing orre t in presen e of repli ated data and inde- pose severe onstraints on s alability by requiring
pendent of the proto ol that maintains su h repli as ausal delivery to be supported by the underlying
oherent among pro esses, it does not require ausal ommuni ation layer.
delivery to be ensured by the underlying ommuni- The rst drawba k, i.e. not onsidering repli-
ations support. In addition, it has minimal perfor- ated data, on erns all the lassi al DGC algo-
man e impa t on appli ations. rithms that were designed for fun tion-shipping
based systems, su h as Indire t Referen e Count-
ing (IRC) [14℄ or SSP Chains [16℄. As a matter of
1 Introdu tion fa t, these algorithms are not safe in presen e of
repli ated data, as explained now.
Modern distributed appli ations sharing long-term Consider Figure 1 in whi h an obje t x is repli-
data over many pla es, geographi ally separated, ated in pro esses i and j; ea h repli a of x is noted x i

appear ea h day. Typi al examples are found in and x , respe tively. Now, suppose that x ontains
j i

the elds of on urrent engineering, ooperative ap- a referen e to an obje t z in another pro ess k, x j

pli ations, et . points to no other obje t, x is lo ally unrea hable

i

Manual memory management is extremely dif- and x is lo ally rea hable1. Then, the question is:
j

 ult when developing the aforementioned dis- 1 Lo ally (un)rea hability is related to (un)a essibility
 process i
local
process j
local
i.e. it is out of the s ope of the paper how the algo-
root root
rithm behaves in presen e of ommuni ation failures
x x and pro esses rashes. However, solutions similar to
those found in lassi al DGC algorithms an also be
applied (for example, leasings as in RMI [18℄.
This paper is organized as follows. In Se tion 2
z we present the model of a WARM for whi h the
local
root
DGC was dened. The DGC algorithm is des ribed
process k in Se tions 3 and 4. Se tion 5 highlights some of
the most important implementation aspe ts. Se -
Figure 1: Safety problem of urrent DGC algo- tion 6 presents some performan e results from a real
rithms whi h do not handle repli ated data: z is appli ation. The paper ends with some related work
erroneously onsidered unrea hable. and on lusions in Se tion 7 and 8, respe tively.

should z be onsidered garbage? Classi al DGC al-

gorithms onsider that z is ee tively garbage. How- 2 WARM Model
ever, this is wrong be ause, in a WARM system,
it is possible for an appli ation in j to \a quire" a
repli a of x from some other pro ess, in parti ular, This se tion presents the model for Wide Area
2
x . Thus, the fa t that x is lo ally unrea hable in
i i
Repli ated Memory (WARM). A WARM is a repli-
pro ess i does not mean that x is globally unrea h- ated distributed memory spanning several pro-
able; as a matter of fa t, x ontents an be a essed
i
esses. These pro esses are onne ted in a network
by an appli ation in pro ess j by means of an \a - and ommuni ate only by asyn hronous message
quire". Therefore, in a WARM system, a target passing. We indi ate that a message M has been
obje t z is onsidered unrea hable only if the union sent from pro ess i to pro ess j as <send:M> ! ; the
i j

of all the repli as of the sour e obje t, x in this ex- delivery of that message is noted <deliver:M> ! . i j

ample, do not refer to it. We all this the Union In a WARM, the only way to share information
Rule (more details in Se tion 4.2.2). is by repli ation of data, whi h an be done with a
The se ond drawba k, i.e. imposing severe DSM based me hanism[12℄. Thus, pro esses do not
onstraints on s alability, ae ts urrent DGC al- use Remote Pro edure Call (RPC) to a ess remote
gorithms on eived for WARM systems, su h as data.
Lar hant [5, 10℄. As a matter of fa t, su h algo- It's worthy to note that appli ation ode inside
rithms are not s alable be ause they require the a pro ess never sends messages expli itly. Instead,
underlying ommuni ation layer to support ausal appli ation ode a ess data always lo ally; trans-
delivery. parently to the appli ation ode, the WARM run-
So, in on lusion, lassi al DGC algorithms, su h time system is responsible to repli ate data lo ally
as IRC and SSP Chains, are not safe for WARM when needed.
systems but promise to be s alable, in parti ular,
do not require ausal delivery; on the other hand, Ea h parti ipating pro ess in the WARM en-
loses, at least, the following entities: memory, mu-
WARM spe i DGC algorithms, su h as Lar hant,
deals safely with repli ation but la ks s alability. tator3 , and a oheren e engine. In our WARM
model, for ea h one of these entities, we onsider
Thus, the main ontribution of this work is the only the operations that are relevant for GC pur-
following: showing how lassi al DGC algorithms poses.
( on eived for fun tion-shipping based systems) an
be extended to handle repli ation while keeping We believe that our model is suÆ iently gen-
their s alability. eral to des ribe most distributed systems support-
We do not address the issue of fault-toleran e, ing wide area appli ations using data shipping. This
model learly denes the environment for whi h the
from the en losing pro ess's lo al root. DGC algorithm is on eived.
2 In distributed systems with repli ated data, an \a quire"
operation allows a pro ess to update its lo al repli a of a par-
ti ular obje t with the ontents of another repli a, of that 3 The term mutator [7℄ designates the appli ation ode
same obje t, residing in some other pro ess with a data- whi h, from the point of view of the garbage olle tor, mu-
shipping me hanism. tates (or modies) the rea hability graph of obje ts.
2.1 Memory Organization
before <x:=y> i after <x:=y> i

An obje t is dened to be a onse utive sequen e process i process i

of bytes in memory. Appli ations an have dierent local
root
local
root
views of obje ts and an see them as language-level y y
lass instan es, memory pages, data base re ords, x x

web pages, et .
Obje ts an ontain referen es pointing to other
obje ts. An outgoing inter-pro ess referen e is z z
a referen e to a target obje t in a dierent pro-
ess. An in oming inter-pro ess referen e is a local
root
local
root
referen e to an obje t that is pointed from a dif- process k process k
ferent pro ess. Our model does not restri t how
referen es are a tually implemented. They an be
virtual memory pointers, URLs, et . Figure 2: Creation of a new inter-pro ess referen e
An obje t is said to be rea hable if it is attain- to obje t z through an assignment operation.
able dire tly or indire tly from a GC root (dened
in Se tion 3.1). An obje t is said to be unrea h-
or deleting referen es. An obje t be omes unrea h-
able if there is no referen e path (dire t or indire t) able when the last referen e to it disappears; when
from a GC root leading to that obje t.
this o urs, su h an obje t an be safely re laimed
The unit for oheren e is the obje t. Any obje t by the garbage olle tor be ause there is no possi-
an be repli ated (i.e. a hed) in any pro ess. A bility for any pro ess to a ess it.
repli a of obje t x in pro ess i is noted x . Ea hi

pro ess an a he a repli a of any obje t for reading

2.3 Coheren e Model
or writing a ording to the oheren e proto ol being
used.
The oheren e engine is the entity of the WARM
that is responsible to manage the oheren e of repli-
2.2 Mutator model
as. The oheren e proto ol ee tively used varies
from system to system and depends on several fa -
The single operation exe uted by mutators, whi h tors su h as the number of repli as, distan es be-
is relevant for GC purposes, is referen e assign- tween pro esses, and others. However, the only o-
ment; this is the only way for appli ations to mod- heren e operation, whi h is relevant for GC pur-
ify the graph of obje ts. poses, is the propagation of an obje t, i.e. the
The referen e assignment operation exe uted by repli ation of an obje t from one pro ess to another.
a mutator in some pro ess i is noted < x := y > . i
The propagation of an obje t y from pro ess i to
This means that a referen e ontained in obje t x pro ess j is noted propagate(y) ! .
is assigned to the value of a referen e ontained in
i j

We assume that any pro ess an propagate a

obje t y.4 This assignment operation results in the repli a into itself as long as the mutator ausing the
reation of a new inter-pro ess referen e from x to propagation holds a referen e to the obje t being
z, as illustrated in Figure 2.
propagated. Thus, if an obje t x is lo ally unrea h-
Obviously, other assignments an delete refer- able in pro ess i, the mutator in that pro ess an
en es transforming obje ts in garbage. For exam- not for e the propagation of x to some other pro ess;
ple, in Figure 2, if the mutators in pro esses i and j however, if some other pro ess j holds a referen e to
perform <x := 0> and <y := 0> , obje t z be omes
i i x, it an request x to be propagated from i to j (as
unrea hable, i.e. garbage, given that there are no o urs in Figure 1).
referen es pointing to it. We assume that, in ea h pro ess, the oheren e
In on lusion, assignment operations (done by engine holds two data stru tures, alled inPro-
mutators) modify the obje t graph either reating pList and outPropList; these indi ate the pro ess
4 This notation is not fully a urate but it simplies the from whi h ea h obje t has been propagated, and
explanation of the DGC algorithm. As a matter of fa t, to the pro esses to whi h ea h obje t has been propa-
be more pre ise we should write x:ref = y:ref (C++ style gated, respe tively 5 . Thus, ea h entry of the inPro-
notation). However, this improved pre ision is not important
for the DGC algorithm des ription and would ompli ate it 5 Usually, this information does exist in the oheren e en-
un-ne essarily. gine in order to manage the repli as.
 inPropList/outPropList to (be imported by) pro ess i. The inPropList and
outPropList re e t this situation.

propObj propProc sentUmess/recUmess

In order to understand how the DGC algorithm
works it is important to emphasize the following as-
pe ts on erning the reation of inter-pro ess refer-
en es. The only way a pro ess an reate an inter-
pro ess referen e is through the exe ution of only
two operations: (i) referen e assignment, whi h is
Figure 3: inPropList and outPropList internal data. performed expli itly by the mutator, and (ii) obje t
propagation, whi h is performed by the oheren e
before propagate(y) j->i after propagate(y)
engine in order to allow the mutator to a ess some
j->i
obje t6 .
process i process j process i process j
local local local local
root root root root

y y y y 3 Distributed Garbage Colle tion

inPropList outPropList inPropList outPropList
Algorithm
y j 0 y i 0
In this se tion we des ribe the DGC algorithm and
z z
its data stru tures. Then, in Se tion 4 we go into
local local more detail by des ribing a prototypi al example
whi h addresses all the aspe ts of the DGC algo-
root root
process k process k
rithm.
The DGC algorithm is an hybrid of tra ing and
Figure 4: Coheren e engine propagates obje t y referen e- ounting. Thus, ea h pro ess has two GC
from pro ess j to pro ess i. The dashed line of y i
omponents: a lo al tra ing olle tor, and a dis-
means that initially, in pro ess i, y is not yet repli- tributed olle tor. Ea h pro ess does its lo al tra -
ated in i. ing independently from any other pro ess. The
lo al tra ing an be done by any mark-and-sweep
pList/outPropList ontains the following information based olle tor. The distributed olle tors, based
(see Figure 3): on referen e- ounting, work together by hanging
asyn hronous messages, as des ribed in the follow-
 propObj - the referen e of the obje t that has ing se tions. In the rest of the paper we fo us on
been propagated into/to a pro ess; distributed olle tion.
 propPro - the pro ess from/to whi h the ob- 3.1 Data Stru tures
je t propObj has been propagated;
 sentUmess/re Umess - bit indi ating if a un- A stub des ribes an outgoing inter-pro ess refer-
rea hable message (more details in Se tion 3.2) en e, from a sour e pro ess to a target pro ess. A
has been sent/re eived. s ion des ribes an in oming inter-pro ess referen e,
from a sour e pro ess to a target pro ess. It is im-
When an obje t is propagated to a pro ess we portant to note that stubs and s ions do not impose
say that its en losed referen es are exported from any indire tion on the native referen e me hanism.
the sending pro ess to the re eiving pro ess; on the In other words, they do not interfere either with
re eiving pro ess, i.e. the one re eiving the propa- the stru ture of referen es or the invo ation me h-
gated obje t, we say that the obje t referen es are anism. They are simply GC spe i auxiliary data
imported. stru tures.
Figure 4 illustrates the ee t of a propagation. A stub stores in its internal data stru tures the
Obje t z has no repli as. Initially, only pro ess j following information:
a hes a repli a of y; thus, both outPropList and
inPropList of pro esses j and i are empty. In ad-
 OutRef - the referen e of the target obje t;
6 For
dition, y points to z. After y has been repli ated
j
example, in some DSM-based systems, when the mu-
from pro ess j to pro ess i, a new inter-pro ess ref- tator tries to a ess an obje t that is not yet a hed lo ally,
a page fault is generated; then, this fault is automati ally
eren e from y to z is reated; this is due to the fa t
i re overed by the oheren e engine that obtains a repli a of
that the referen e to z was exported from pro ess j the faulted obje t from some other pro ess.
  Sour eObj - the referen e of the lo al obje t  When an outgoing inter-pro ess referen e is
ontaining the outgoing inter-pro ess referen e; found the orresponding stub is reated in the
new set of stubs.
 S ion - the identi ation of the orresponding
s ion; and  For an obje t whi h is rea hable only from the
inPropList, a message unrea hable is sent to the
 Chain - the identi ation of a stub or a s ion site from where that obje t has been propa-
in the same pro ess. gated; this sending event is registered by hang-
ing a sentUmess bit in the orresponding inPro-
A s ion stores in its internal data stru tures the fol- pList entry from 0 to 1.
7
lowing information:
When a unrea hable message rea hes a pro ess,
 InRef - the referen e of the target obje t; this delivery event is registered by hanging a
re Umess bit in the orresponding outPropList
 Stub - the identi ation of the orresponding entry from 0 to 1.
stub; and
 For an obje t whi h is rea hable only from the
 Chain - the identi ation of a stub or a s ion outPropList, and the en losing pro ess has al-
in the same pro ess. ready re eived a unrea hable message from all
Finally, a pro ess's GC root in ludes: (i) the the pro esses to whi h that obje t has been pre-
lo al root, i.e. sta ks and stati variables, (ii) the viously propagated, a re laim message is sent to
set of s ions of that pro ess, and (iii) the lists inPro- all those pro esses and the orresponding en-
pList and outPropList. tries in the outPropList are deleted; otherwise,
nothing is done.
3.2 Algorithm When a pro ess re eives a re laim message it
deletes the orresponding entry in the inPro-
The lo al and distributed olle tors depend on ea h pList.

other to perform their job in the following way. A

lo al olle tor running inside a pro ess tra es the 3.2.2 Distributed Colle tor
obje t graph lo ally a hed; the starting point of
the tra e is the pro ess's GC root. A lo al tra - The main ideas behind the DGC algorithm an be
ing generates a new set of stubs; it is based on this summarized as follows.
new set that the distributed olle tor, in that pro-  As already mentioned, an obje t an be re-
ess, may de ide to update remote s ions in other laimed only when all its repli as are no longer
pro esses.
rea hable. This is ensured by tra ing the ob-
je ts graph from the lists inPropList and out-
3.2.1 Lo al Colle tor PropList; obje ts that are rea hable only from

The lo al olle tor starts the graph tra ing from the these lists are not lo ally rea hable (i.e. by the
pro ess's lo al root and set of s ions. For ea h out- lo al mutator); however, they an not be re-
going inter-pro ess referen e it reates a stub in the laimed without ensuring their global unrea h-
new set of stubs. On e this tra ing is ompleted, ability, i.e. that none of their repli as are a -
every obje t lo ally rea hable by the mutator has essible. This will be explained in detail in the
been found (e.g. marked, if a mark-and-sweep algo- following se tion.
rithm is used); obje ts not yet found are lo ally un-  The DGC algorithm is independent of the par-
rea hable; however, they an still be rea hable from ti ular oheren e proto ol implemented by the
some other pro ess holding a repli a of, at least, oheren e engine. In other words, the DGC al-
one of su h obje ts (as is the ase of x in Figure 1).
i
gorithm does not require waiting for repli as to
To prevent the erroneous deletion of su h obje ts, be oherent.
the olle tor tra es the obje ts graph from the lists
7 Note that from now on, the repli a is not rea hable by the
inPropList and outPropList, and performs as follows.
lo al mutator; if another propagate operation o urs bring-
 When a lo ally rea hable obje t (previously ing a new repli a of that same obje t into the pro ess, the
old repli a remains lo ally unrea hable, and a new entry is
dis overed by the lo al olle tor) is found, the reated in the inPropList with the orresponding sentUmess
tra ing along that referen e path ends. set to 0.
 message sent/re eived by sent when
unrea hable LGC/DGC obje t repli a is rea hable only from the inPropList
re laim LGC/DGC all obje t repli as are rea hable only from the inPropLists
newSetStubs DGC/DGC a new set of stubs is available

Table 1: GC related messages.

 Whatever the oheren e proto ol, there is only 4 Prototypi al Example

one intera tion with the DGC algorithm. This
intera tion is twofold: (i) immediately before We use a prototypi al example, illustrated in Fig-
a propagate message is sent, the referen es be- ures 5 and 6. This example evolves along a sequen e
ing exported ( ontained in the propagated ob- of steps overing all the situations, relevant for GC,
je t) must be found in order to reate the or- that o ur in a WARM: (i) reation of a new out-
responding s ions, and (ii) immediately before going inter-pro ess referen e by means of a propa-
a propagate message is delivered, the outgoing gate operation, (ii) reation of a new outgoing inter-
inter-pro ess referen es being imported must be pro ess referen e by means of an assignment opera-
found in order to reate the orresponding lo al tion, and (iii) deletion of outgoing inter-pro ess ref-
stubs, if they do not exist yet.8 eren es by means of assignment and propagate op-
 From time to time, possibly after a lo al olle - erations. We show how all these o urren es ae t
tion, the distributed olle tor sends a message the GC spe i data stru tures and messages.
alled newSetStubs; this message ontains the In the initial situation both x and y are a hed
new set of stubs that resulted from the lo al in pro esses i and j. However, only the repli a y j

olle tion; this message is sent to the pro esses points to obje t z in pro ess k. There is a single
holding the s ions orresponding to the stubs stub-s ion pair (s2-s1) des ribing the only outgoing
in the previous stub set. In ea h of the re eiv- inter-pro ess referen e from y to z. For the sake of
j

ing pro esses, the distributed olle tor mat hes simpli ity of our des ription, we assume that this
the just re eived set of stubs with its set of stub-s ion pair is reated when the system boots.9
s ions; those s ions that no longer have the or- Then, the sequen e of steps of the prototypi al
responding stub, are deleted. example onsiders the following operations (see Fig-
ures 5 and 6; the ee ts of the operations are shown
 As previously des ribed, when a lo al olle - in bold).
tion takes pla e two kinds of messages may be
sent: unrea hable and re laim. On the re eiving Step 1 - Propagate y from pro ess j to pro ess
pro ess, these messages are handled by the dis- i; this results in the reation of a new outgo-
tributed olle tor that performs the following ing inter-pro ess referen e from obje t y in i to
operations: sets the re Umess bit in the or- obje t z in k.
responding outPropList entry, and deletes the
orresponding entry in the inPropList, respe - Step 2 - The operation <x := y> is performed
i

tively. by the mutator in i; this reates a new outgo-

ing inter-pro ess referen e from obje t x in i to
 The DGC algorithm does not require the un- obje t z in k.
derlying ommuni ation layer to support ausal
delivery. Step 3 - Propagate x from pro ess i to pro ess
Table 1 presents all the GC related messages of j; this results in the reation of a new outgo-

the model, the omponents responsible for sending ing inter-pro ess referen e from obje t x in j to
and re eiving them, and when they o ur. In Ta- obje t z in k.
ble 2 we present all the events with impa t on the
GC and the orresponding a tions taken. These two Step 4 - The operation <y := 0> is performed
j

tables summarize the way GC is performed. In the by the mutator in j; this results in the deletion
next se tion we des ribe the DGC algorithm in more of an outgoing inter-pro ess referen e from ob-
detail using a prototypi al example. je t y in j to obje t z in k.
8 Note that this may result in the reation of hains of stub- 9 For example, the referen e to z ould be obtained from a
s ion pairs, as it happens in the SSP Chains algorithm [16℄. name servi e.
 event o urs when a tion taken
referen e exported propagate an obje t reate s ion
from a pro ess
referen e imported propagate an obje t reate stub
into a pro ess
obje t repli a LGC runs send unrea hable message to
rea hable only the pro ess with the orresponding
from the inPropList outPropList entry; set the
sentUmess bit a ordingly
unrea hable message unrea hable message sent set the re Umess bit a ordingly;
re eived if all re Umess bits for a
parti ular obje t are set, then send
the orresponding re laim messages
and delete the outPropList entry
re laim message re laim message sent delete orresponding inPropList
re eived entry
new set of stubs LGC runs newSetStubs message sent to the
available pro esses holding the s ions orres-
ponding to the previous set of stubs
newSetStubs message newSetStubs message sent ompare stubs set with set of s ions;
re eived delete s ions with no
orresponding stubs

Table 2: GC related events.

Step 5 - Propagate y from pro ess j to pro ess i; 2), and nally by propagation again (step 3). We
this results in the deletion of an outgoing inter- address these ases now.
pro ess referen e from obje t y in i to obje t z
in k. 4.1.1 Propagation
Step 6 - The operation <x := 0> is performed
i
The rst operation in the prototypi al example is
by the mutator in i; this results in the deletion propagate(y) ! (Figure 5, step 1). Immediately be-
of an outgoing inter-pro ess referen e from ob- j i

fore this message is sent from pro ess j, obje t y

je t x in i to obje t z in k. must be s anned for referen es being exported. For
Step 7 - the mutator in j deletes the referen e ea h one of these referen es, the orresponding s ion
from the lo al root to obje t x. must be reated. In this ase, y ontains only one
referen e (pointing to z); the orresponding s ion s3
Step 8 - the mutator makes x unrea hable by
i is shown in bold. Note that the s ion just reated,
deleting the referen e from the lo al root; thus, through its Chain eld, refers to the already exist-
every repli a of x be omes garbage. ing stub s2 (des ribing the outgoing inter-pro ess
The prototypi al example presented above has referen e from obje t y to obje t z).
two parts: the rst three steps results in the re- Immediately before propagate(y) ! is delivered
j i

ation of new outgoing inter-pro ess referen es; the in pro ess i, obje t y has to be s anned for imported
last ve steps result in z be oming unrea hable. In outgoing inter-pro ess referen es in order to reate
the next se tions we des ribe how the DGC works the orresponding stubs in pro ess i, if they do not
in order to deal with this prototypi al example. exist yet. In the prototypi al example, y ontains
a single referen e and there is no stub des ribing
4.1 Creation of Outgoing Inter-pro ess it in pro ess i. Thus, the orresponding stub s4 is
Referen es reated (shown in bold); this stub, through its in-
ternal data stru tures, refers to the s ion previously
In the prototypi al example, the reation of outgo- reated in pro ess j. Then, the mutator may freely
ing inter-pro ess referen es o urs rst by propa- a ess obje t y in pro ess i.
gation (step 1), then by referen e assignment (step Thus, the information stored in the stub-s ion
 process i process j
inPropList local local outPropList
root root
xj 0 xi 0
y y
yj 0 x S3 z x yi 0
z z
S4 S2

z
z S1
local
root
process k
Step 1: propagation of object y from process j to process i.

process i process j
inPropList local local outPropList
root root
xj 0 xi 0
y y
yj 0 x S3 z x yi 0
z z
S4 S2

z
z S1
local
root
process k
Step 2: creating a new inter-process reference through <x:=y> i.

process i S6 process j z S7
local z local
inPropList outPropList
root z S5 root

xj 0 y y xi 0
yj 0 x S3 z x yi 0
z z
S4
S2

z
z S1
local
root
process k
Step 3: propagation of object x from process i to process j.

S7
process i S6 process j z
local z local
inPropList root root outPropList
z S5
xj 0 y y xi 0
yj 0 x S3 z x yi 0
z z
S4
S2
X

z
z S1
local
root
process k
Step 4:deleting an inter-process reference through <y:=0> j .

Figure 5: Prototypi al example (part 1).

 process i process j S7
S6 z
local
z local
root S5 root outPropList
inPropList z
xj 0 y y xi 0
yj 0 x S3 z x yi 0
z
S4
X z
S2

z
z S1
local
root
process k
Step 5: propagation of object y from process j to process i.
process j S7
process i S6 z
local z local
root S5 root outPropList
inPropList z
y xi 0
xj 0 y x
yj 0 x S3 z yi 0
z z
S4 S2

X z
z S1
local
root
process k
Step 6:deleting an inter-process reference through <x:=0> .
i

process j S7
process i S6 z
local z local
inPropList root z S5 root outPropList
X
xj 0 y y xi 0
yj 0 x S3 z x
yi 0
z z
S4 S2

z
z S1
local
root
process k
Step 7:object x in process j becomes unreachable from the local root.

process j S7
process i S6 z
local
z
S5 local
inPropList root outPropList
z root
X

xj 0 y y xi 0
yj 0 x S3 z x yi 0
z z
S4
S2

local z S1
root
process k
Step 8:object x in process i becomes unreachable from the local root.

Figure 6: Prototypi al example (part 2).

pair just reated, s4-s3, is the following: 4.1.3 Propagation
 stub s4 : refers to obje t z in pro ess k,
OutRef The third step of the prototypi al example is the
sour eObj refers to obje t y in pro ess i, S ion propagation of obje t x from pro ess i to pro ess
identies the orresponding s ion s3 previously j. This results in the reation of a new outgoing
reated in pro ess j, and Chain is null; inter-pro ess referen e: from obje t x in pro ess j to
 s ion s3: InRef refers to obje t z in pro ess k,
obje t z in pro ess k(shown in bold in Figure 5, step
Stub identies the orresponding stub s4 in pro- 3).
ess i, and Chain refers to the stub des ribing A ording to Safety Rule Clean Before Send
the outgoing inter-pro ess referen e from obje t Propagate, before the propagate message is sent,
y to obje t z.
the following has to be done in pro ess i: s an obje t
x, nd its en losed referen es and reate the orre-
It is worthy to note that the mutator does not sponding s ions. In this ase, obje t x has only one
have to be blo ked while the GC spe i operations referen e; thus, as a result of the s an, s ion s6 is
mentioned above are exe uted (s anning the obje t reated in pro ess i (shown in bold, Figure 5, step
being propagated and reating the orresponding 3).
s ion and stub); su h operations an be exe uted In addition, it is reated stub s5 des ribing the
in the ba kground. outgoing inter-pro ess referen e from obje t x in
To summarize, there are the following rules: pro ess i to obje t z in pro ess k.10
Safety Rule I: Clean Before Send A ording to Safety Rule Clean Before Deliver
Propagate. Before sending a propagate Propagate, before the propagate message is deliv-
message for an obje t y from a pro ess j, y ered in pro ess j, obje t x must be leaned and the
must be leaned (i.e. it must be s anned for orresponding stub s7 reated (shown in bold, Fig-
referen es) and the orresponding s ions ure 5, step 3).
reated in j.
4.2 Deletion of Outgoing Inter-pro ess
Safety Rule II: Clean Before Deliver Referen es
Propagate. Before delivering a propa-
gate message for an obje t y in a pro ess i, In the prototypi al example, the deletion of outgo-
y must be leaned (i.e. it must be s anned ing inter-pro ess referen es o urs rst by referen e
for outgoing inter-pro ess referen es) and assignment, then by propagation, then by referen e
the orresponding stubs reated in i, if they assignment again, and nally by propagation again.
do not exist yet. After all these operations, obje t z is unrea hable.
We address these steps now.
4.1.2 Assignment
The se ond step of the prototypi al example is the 4.2.1 Assignments and Propagations
exe ution of the operation <x := y> . This results
The fourth step of the prototypi al example is the
i

in the reation of a new outgoing inter-pro ess ref-

eren e: from obje t x in pro ess i to z in pro ess exe ution of the operation <y := 0> . This results in
j

k. There is absolutely no operation to be done on

the deletion of the outgoing inter-pro ess referen e,
behalf of the DGC algorithm. from obje t y to obje t z (Figure 5, step 4). At this
This might seem strange be ause, a ording to moment, there is absolutely no operation to be done
traditional referen e ounting algorithms [20℄, ea h for GC purposes.
time a referen e is reated, a ounter (at least) must The fth step of the prototypi al example is
be in remented. In a WARM, where mutators may propagate(y) ! . Given that the repli a that is be-
j i

reate inter-pro ess referen es very easily and fre- ing propagated to i no longer points to any obje t,
quently, through a simple referen e assignment op- after the propagate is delivered, the outgoing inter-
eration, su h in rement would be extremely ineÆ- pro ess referen e from obje t y in pro ess i to z, is
ient. As a matter of fa t, this would require instru- (impli itly) deleted (Figure 6, step 5). At this mo-
menting every referen e assignment and in rement ment, there is absolutely no operation to be done for
a ounter a ordingly, possibly on some remote pro- GC purposes. Note that, given that the obje t be-
ess. In the following se tions it will be ome lear ing propagated ontains no referen es, both safety
that su h in rement (or equivalent operation) does 10 Note that if a lo al olle tion has previously taken pla e
not need to be performed immediately. in pro ess i, stub s5 would have been already reated.
 proc. i z
S6

S5
. ..
root(x)=0
inPropList
xj0 LGC
. inPropList
xj1
inPropList

S4
z

z S5
S6

. . . S4 X
z
S6

S5 S4
LGC

Xz zX

new
S4 yj0

unr
yj0 yj0 z t

bs
z z z z S5

im(x)

etStu
eac
. .. . . . ..

Set
hab

Stu
S3

newS
S3

recla
S3 S7 outPropList outPropList outPropList S7
X

le(x

bs
S3 S3
X
z z
proc. j z xi0 xi1 LGC LGC z z z z LGC

)
S2 yi0 S2 S2 S2
X
yi0 yi0 S2 z z

new
z z z S2 z t

. .

Set
Stu
S1 S1 S1 S1 S1
S1
z Xz LGC
S1

bs
proc. k z z z z z

t
8th step: initial situation 1st LGC 2nd LGC 3rd LGC 4th LGC 5th LGC 6th LGC

Figure 7: Timeline des ribing the GC operations after the 8th step of the prototypi al example.

rules do not imply the exe ution of any parti ular When this message is delivered in pro ess j, the
operation. re Umess bit in the orresponding entry of out-
The sixth step of the prototypi al example is the PropList is set.
exe ution of the operation <x := 0> . This results in
the deletion of the outgoing inter-pro ess referen e,
i
2nd LGC - The lo al olle tor in pro ess j de-
from obje t x in pro ess i to obje t z in pro ess k te ts that obje t x is rea hable only from the
outPropList and the orresponding entry has its
(Figure 6, step 6). At this moment, there is abso-
re Umess bit set to one; thus a message re laim
lutely no operation to be done for GC purposes.
The seventh step of the prototypi al example is sent to pro ess i and the entry in the outPro-
pList is deleted.
makes obje t x in pro ess j unrea hable from the
lo al root. The last step makes obje t x in pro ess When this message is delivered in pro ess i, the
i unrea hable from the lo al root. In both ases orresponding entry in inPropList is deleted.
there is absolutely no operation to be done for GC 3rd LGC - As a result of a lo al olle tion in
purposes. pro ess j, x is re laimed and, onsequently, stub
So far, the DGC has performed no operation. In s7 des ribing its outgoing inter-pro ess refer-
parti ular, no s ion has been deleted. Consequently, en e to obje t z is not in the new set of stubs.
obje t z, whi h is no longer rea hable, has not been This new set of stubs is sent as a newSetStubs
re laimed yet. This will happen only after its pro- message from pro ess j to pro ess i; then, the
te ting s ion s1 in pro ess k is deleted and the lo al distributed olle tor in i deletes the orrespond-
olle tor is exe uted. Now we address the modi a- ing s ion s6.
tion and deletion of stubs and s ions.
Note that stub s2, in spite of the fa t that y in
j holds no outgoing inter-pro ess referen e any-
4.2.2 Colle ting Garbage
more, is still in the new set of stubs be ause is
In step 8 of the prototypi al example we see that rea hable from s ion s3 through its Chain data
obje t z will be re laimed by the lo al olle tor in stru ture.
pro ess k only after its prote ting s ion s1 has been
deleted. This s ion will be deleted only after the 4th LGC - As a result of a lo al olle tion in
orresponding stub s2 in pro ess j has disappeared; pro ess i, obje t x is re laimed and the new
this will o ur only after all the hain of stub-s ion set of stubs does not ontain any stub (s5 and
s4, in parti ular) be ause there are no outgoing
pairs s7-...-s3 gets deleted.
A ording to Se tion 3.2, the stubs and s ions inter-pro ess referen es.
will disappear as a result of the lo al and distributed This new set of stubs is sent as a newSetStubs
olle tors in pro esses i and j, as explained now (see message from pro ess i to pro ess j; then, the
Figure 7). distributed olle tor in j deletes the orrespond-
ing s ion s3.
1st LGC - The lo al olle tor in pro ess i de-
te ts that obje t x is rea hable only from the 5th LGC - As a result of a lo al olle tion in
inPropList; thus, a message unrea hable is sent pro ess j a new set of stubs is generated in
to pro ess j and the orresponding sentUmess whi h there is no stub (i.e. s2) be ause there
bit is set. are no outgoing inter-pro ess referen es.
 This new set of stubs is sent as a newSet- site S1 site S2
Stubs message from pro ess j to pro ess k; then,
standard HTTP protocol
the distributed olle tor in k deletes the orre- NG client
(with a web browser NG protocol: make-replica
NG server
(web server
sponding s ion s1. component inside) DGC protocol with servlets)

files are accessed with any tool and files are accessed with any tool and

6th LGC - Finally, a lo al olle tion o urs in made available by means of a web
server
made available by means of a web
server

pro ess k and obje t z is re laimed. NG server

standard HTTP protocol
NG protocol: make-replica NG client
(web server DGC protocol (with a web browser
In on lusion, we have the following rule for repli- with servlets) component inside)

ated obje ts:

Safety Rule III: Union Rule. A target Figure 8: General ar hite ture of the NG appli a-
obje t z is onsidered unrea hable only if tion. Obviously, any number of sites is supported
the union of all the repli as of the sour e and not all are for ed to have both a lient and a
obje ts do not refer to it. server, i.e. some an be just lients or servers.
In the prototypi al example the obje ts pointing user in site S1 site S2
to z were the repli as of x and y. From Figure 7 it is
lear that the union rule is respe ted. In addition, i) browse the NG site S2
web page
it is lear that there is no need for ausal delivery ii) make-replica of a page

to be ensured by the ommuni ation layer. iii) edit the replica

5 Implementation iv) make the replica

available through NG
server in site S1
URLs to other pages at
S2 and other sites

We implemented our WARM distributed and lo-

al garbage olle tors within a system alled News
Gathering (NG). In this se tion we brie y des ribe Figure 9: Example of NG usage: i) browse the S2
the NG appli ation; then, we fo us on the most im- web site, ii) make-repli as of a page, iii) edit the
portant implementation aspe ts of the DGC: how repli a, and iv) make the repli a available for others.
the safety rules are implemented, and the stub/s ion
data stru tures. the user's lo al NG server. These repli as may hold
referen es to other (not lo ally repli ated) S2 pages.
5.1 NG Appli ation Thus, it is desirable that su h pages in the S2 web
site remain available as long as there are referen es
NG is a web-based lient-server appli ation that we pointing to them. Figure 9 illustrates this s enario.
developed, to support the sharing of les over the The NG appli ation, due to the WARM dis-
web by means of repli ation [19℄. From the user tributed garbage olle tor, ensures that su h pages
point of view the lient side of NG is a normal web at the S2 site remain there as long as they are
browser with an extra menu button alled \make- pointed from some other NG site. In addition, les
repli a". This fun tion allows the user to propagate at the S2 site, whi h are no longer referen ed from
a le into his ma hine, i.e., to reate a lo al repli a any other NG site are automati ally deleted by the
of the le he is looking at. On e repli ated, the le garbage olle tor. This means that neither dangling
an be freely a essed with any other appli ation referen es nor memory leaks o ur.
(possibly making the repli as to diverge). Later, The NG appli ation is implemented in Java; this
this repli a an be propagated ba k to the site from in ludes the lient ode (that uses the Mi rosoft In-
where it ame from by means of a make-repli a oper- ternet Explorer omponent) and the servlets run-
ation performed by other user running on that site. ning within an Apa he web server.
(Figure 8 illustrates the general ar hite ture of this
appli ation.) 5.2 Distributed Garbage Colle tor
With NG, a typi al user in site S1 browses the
web (web servers supporting the NG appli ation) All the ode of the lo al and distributed olle tors is
and makes-repli as of some of the pages from, for written in Java. The lo al olle tor is implemented
example, the S2 site. These pages are then edited as a stand-alone appli ation. The distributed olle -
by the user and, on e ready, are made available from tor is implemented by the servlets and by the lient.
 time to perform a make-replica
hash table for ea h site holding s ions orresponding
to the stubs in that table. Sending a new set of
client C1 scan F1, create stubs
t
stubs to a parti ular site is just a matter of sending
make-replica (F1)
the new hash table. The same reasoning applies to
ack
s ions: they are stored in hash tables, ea h table
server scan F1, create scions, find auxiliary file, grouping the s ions whose orresponding stubs are
store URLs in auxiliary file create scions t
in the same site.
make-replica (F1) ack

client C2 scan F1, create stubs

t
6 Performan e
time to perform a make-replica
In this se tion we present the most relevant per-
forman e results on erning the DGC. The riti al
Figure 10: Propagation of le F1. performan e results are those related to the imple-
mentation of safety rules I and II.
Basi ally, the ode in the servlets implements Thus, we downloaded a well-known web site
the safety rule Clean Before Send Propagate (ap- ( nn. om) and ran on ea h le the ode implement-
plied when a make-repli a is requested); the lient ing the safety rules. All results were obtained in a
ode implements the safety rule Clean Before De- lo al 100 Mbits network, onne ting PCs with Win-
liver Propagate (applied when the reply to a make- dows NT, with 64 Mb of memory and a Pentium II
repli a request is re eived). The implementation of at 233 MHz.
these rules onsists on s anning the web pages being We downloaded all the 155 HTML les of the
propagated and reating the orresponding s ions nn. om web site12 and obtained for ea h one the
(at the server) and stubs (at the lient). time it takes to: s an it, reate the orresponding
The rst time a le is propagated, at the server stubs, and serialize the hash table (in luding writing
site its ontents are s anned, the orresponding to disk). In this se tion, for larity, we simply refer
s ions reated, and the en losed set of URLs is kept to the time it takes to reate stubs and their size
in an auxiliary le. Later, if this same page is prop- be ause the same values apply to s ions.
agated again, at the server site it only has to be
s anned again if it has been modied after the last
s an. The timeline presented in Figure 10 shows
how the s anning needed to enfor e safety rules I le number s an stub hash time
and II relates to the make-repli a request of le size of time reation table to se-
F1 11 . URLs time size rialize
Another important aspe t on erning the imple- 43563 326 38 3 19252 67
mentation of the garbage olle tors (both lo al and
distributed) is the data stru tures supporting the
stubs and s ions. These were on eived taking into Table 3: Mean values obtained with all the les
a ount their use, in parti ular, to optimize the kind automati ally downloaded from the nn. om site
of information ex hanged between sites that o urs (Sizes in bytes and times in millise onds.).
when a newSetStubs message is sent.
This message implies that the new set of stubs,
resulting from a lo al olle tion, is sent to the pro- In Table 3 we present, for ea h one of the 155
esses holding the s ions orresponding to the stubs les: the mean le size, the mean number of URLs
in the previous stub set. Then, in ea h of the re- en losed in ea h le, the mean time to s an a le,
eiving pro esses, the distributed olle tor mat hes the mean time it takes to reate a stub in the or-
the just re eived set of stubs with its set of s ions; responding hash table, the mean size of the hash
those s ions that no longer have the orresponding table ontaining all the stubs orresponding to all
stub, are deleted. the URLs en losed in a le (that depends on the
Thus, stubs are grouped by site, i.e. there is one size of the orresponding URL), and the mean time
11 Note that the lient an s an the page immediately af- 12 Using an automati tool alled WebReaper available from
ter sending a make-repli a request be ause its ontents are http://www.otway. om/webreaper ongured with a depth
already available lo ally (for browsing). level of 5.
 le le number s an stub hash URLs time to
name size of URLs time reation table size serialize
time size
europe.htm 49055 493 36 10 25485 22367 60
health.htm 102933 491 45 10 26268 23465 60
law.htm 79460 523 117 10 31373 30194 70
main.htm 67081 588 40 10 38548 34108 71
politi s.htm 59079 470 90 10 25963 22939 60
showbiz.htm 71579 498 40 10 26481 24944 111
spa e.htm 58488 478 78 50 24835 23614 50
sports.htm 41778 366 27 10 23308 18908 60
te h.htm 49645 462 34 10 21820 20491 50
world.htm 54863 554 40 10 24489 23870 50

Table 4: Values for the top-set group of les. (Sizes in bytes, times in millise onds.)

le le number s an stub hash URLs time to

name size of URLs time reation table size serialize
time size
index.htm 46960 360 27 10 22692 21400 60
default.htm 48419 380 33 10 24504 23870 50
01/index.htm 45504 369 95 10 22817 22444 60
02/index.htm 26753 200 16 20 14084 10789 40
03/index.htm 31834 279 22 10 18493 17033 50
04/index.htm 45247 360 26 10 21855 21656 50
05/index.htm 53778 411 30 10 25817 24490 60
06/index.htm 42476 362 25 10 22706 22081 70
01/default.htm 16843 150 20 10 8032 7934 10
02/default.htm 33473 173 24 10 8675 8090 30

Table 5: Values for the bran h-set group of les in the bran h world/europe. (Sizes in bytes, times in
millise onds.)

it takes to serialize a hash table with all the stubs In Tables 4 and 5, for ea h le in the top-set and
orresponding to a single le. in the bran h-set, respe tively, we present the times
However, in a normal browsing session, the user mentioned above along with the size of ea h le and
does not makes-repli a of all the les. We expe t the number of URLs en losed.
the user to browse a few top-level pages and then These performan e results are worst- ase be ause
pi k one or more bran hes of the hierar hy. Some they assume all the URLs en losed in a le refer to a
of these les will be repli ated into the users lo al le in another site, whi h is not the usual ase. How-
omputer. ever, they give us a good notion of the performan e
So, in order to obtain more realisti numbers, we limits of the urrent implementation. In parti ular,
performed the following. We pi ked 10 les from we see that the most relevant performan e osts are
the top of the nn. om hierar hy. These les are due to the s anning of a le and the serialization of
mostly entry points to the others with more spe i the hash table. However, we believe that these val-
ontents. We all this set of les, the top-set. We ues are a eptable taking into a ount the fun tion-
also pi ked other 10 les representing a bran h of ality of the system, i.e. it ensures that no dangling
the nn. om hierar hy. We all this set of les, the referen es and no memory leaks o ur. In addition,
bran h-set. when a user runs the NG browser and a esses any
web page without making a lo al repli a of any le, Previous work in DGC as IRC [14℄, SSP
there is absolutely no performan e overhead due to hains [16℄ and Lar hant [10℄ served as the starting
DGC. point of the DGC algorithm presented in this paper.
We an also on lude that the size on disk of the Our new algorithm builds on these previous two al-
hash table ontaining all the stubs for a le is about gorithms in su h a way that ombines their advan-
half the size of the HTML le. This rather large tages: no need for ausal delivery support to be pro-
size is mostly due to the size of the URLs whi h are vided by the underlying ommuni ating layer (from
responsible for about 90% of that size. The size of the rst two), and apability to deal with repli ated
the le ontaining the stubs an ertainly be redu ed obje ts (from Lar hant).
using regular ompression te hniques.

8 Con lusions and Future Work

7 Related work
In this paper we presented a new DGC algorithm
Mu h previous work in distributed garbage olle - for a WARM. The algorithm is general enough to be
tion, su h as SSP Chains [16℄ or Network Obje ts widely appli able given the minimal assumptions of
[4, 18℄, onsiders pro esses ommuni ating by mes- the underlying model.
sages (without shared memory), using a hybrid of The fundamental aspe ts of the DGC algorithm
tra ing and ounting. Ea h pro ess tra es its inter- are the following.
nal pointers; referen es a ross pro ess boundaries
are ounted as they are sent in messages.  It does not interfere with the proto ol that
Some obje t-oriented databases use a similar ap- maintains the repli as oherent among the par-
proa h [2, 6, 21℄, i.e. a partition an be olle ted ti ipating pro esses. This means that the DGC
independently from the rest of the database. In par- does not require repli as to be oherent.
ti ular, Thor is a resear h OODB [13℄ that stores
data in a small number of servers. This data is  It does not require ausal delivery to be sup-
a hed at workstations for pro essing. A Thor ported by the underlying ommuni ation layer.
server ounts referen es ontained in obje ts a hed Given that supporting ausal delivery in wide
at a lient. Thor defers ounting referen es origi- area networks is diÆ ult and ineÆ ient, this is
nating from some obje t x a hed at a lient, until a fundamental aspe t to ensure the DGC algo-
x is modied at the server. rithm s alability.
The work most dire tly related to this one is
Skubiszewski and Porteix's GC- onsistent uts [17℄.  It is safe in presen e of repli ated obje ts, i.e.
They onsider asyn hronous tra ing of an obje t- it respe ts the union rule.
oriented database, with no distribution or repli a-
tion. The olle tor is allowed to tra e an arbitrary We presented our DGC algorithm as an evolution
database page at any time, subje t to the follow- of two previous ones: a lassi al one designed for dis-
ing ordering rule. For every transa tion a essing tributed systems based on fun tion-shipping with
a page tra ed by the olle tor, if the transa tion no repli ation support, SSP hains, and Lar hant
opies a pointer from one page to another, the ol- whi h is targeted to distributed systems with repli-
le tor either tra es the sour e page before the write, ated obje ts. However, it's important to note that
or tra es both the sour e and the destination page any lassi al distributed garbage olle tion algo-
after the write. The authors prove that this is a rithm based on referen e- ounting an be used in-
suÆ ient ondition for safety and liveness. stead of SSP Chains (e.g. IRC). The only require-
Most previous work on garbage olle tion in ment would be its integration with the WARM in
shared memory deals either with multipro essors su h a way that the safety rules are respe ted.
[3, 8℄ or with a small-s ale DSM [9, 11℄. These au- Con erning future resear h dire tions, we intend
thors make strong oheren e assumptions, and they to address the fault-toleran e of the DGC algorithm.
ignore the fundamental issue of s alability. In other words, we are starting to study how the
Yu and Cox [22℄ des ribe a onservative ol- DGC algorithm should be designed so that it an
le tor for the TreadMarks DSM system. It uses remain safe, live and omplete in spite of pro ess
partitioned GC on a pro ess basis; it is strongly rashes and permanent ommuni ation failures. We
integrated with TreadMarks and all messages are are also investigating how the DGC algorithm is af-
s anned for possible ontained pointers. fe ted if the WARM is a essed using transa tions.
Referen es Saint-Malo (Fran e), September 1992. Springer-
Verlag.
[1℄ Saleh E. Abdullahi, and Graem A. Ringwood. [12℄ Kai Li and Paul Hudak. Memory oheren e in
Garbage olle ting the internet: A survey of dis- shared virtual memory systems. ACM Transa -
tributed garbage olle tion. ACM Computing Sur- tions on Computer Systems, 7(4):321{359, Novem-
veys, 30(3):330{373, September 1998.
ber 1989.
[2℄ L. Amsaleg, M. Franklin, and O. Gruber. EÆ ient [13℄ U. Maheshwari and B. Liskov. Fault-tolerant dis-
In remental Garbage Colle tion for Client-Server tributed garbage olle tion in a lient-server, ob-
Obje t Database Systems. In Pro . of the 21th je t database. In Pro eedings of the Parallel and
VLDB Int. Conf., Z uri h, Switzerland, September Distributed Information Systems, pages 239{248,
1995. Austin, Texas (USA), September 1994.
[3℄ Andrew W. Appel. Simple Generational Garbage [14℄ Jose M. Piquer. Indire t referen e- ounting,
Colle tion and Fast Allo ation. Software Pra ti e a distributed garbage olle tion algorithm. In
and Experien e, 19(2):171{183, February 1989.
PARLE'91|Parallel Ar hite tures and Languages
[4℄ Andrew Birrell, Greg Nelson, Susan Owi ki, and Europe , volume 505 of Le ture Notes in Computer
Edward Wobber. Network obje ts. Software S ien e , pages 150{165, Eindhoven (the Nether-
Pra ti e and Experien e, S4(25):87{130, De ember lands), June 1991. Springer-Verlag.
1995. [15℄ David Plainfosse and Mar Shapiro. A survey of
[5℄ Xavier Blondel, Paulo Ferreira, and Mar Shapiro. distributed garbage olle tion te hniques. In Pro .
Implementing garbage olle tion in the PerDiS sys- Int. Workshop on Memory Management, Kinross
tem. In Pro . of the Eigth International Workshop S otland (UK), September 1995.
on Persistent Obje t Systems: Design, Implemen-
[16℄ Mar Shapiro, Peter Di kman, and David Plain-
tation and Use (POS-8) , 1998.
fosse. SSP hains: Robust, distributed referen es
[6℄ Jonathan E. Cook, Alexander L. Wolf, and Ben- supporting a y li garbage olle tion. Rapport de
jamin G. Zorn. Partition sele tion poli ies in obje t Re her he 1799, Institut National de Re her he
database garbage olle tion. In Pro . Int. Conf. en Informatique et Automatique, Ro quen ourt
on Management of Data (SIGMOD), pages 371{ (Fran e), November 1992.
382, Minneapolis MN (USA), May 1994. ACM SIG-
MOD. [17℄ Mar in Skubiszewski and Patri k Valduriez. Con-
urrent Garbage Colle tion in O2 . In Pro eedings of
[7℄ Edsger W. Dijkstra, Leslie Lamport, A. J. Martin, the 23rd VLDB Conferen e, Athens Gree e, 1997.

Sun Mi rosystems In . JavaTM Remote Method

C. S. S holten, and E. F. M. Steens. On-The-Fly
Garbage Colle tion: An Exer ise in Cooperation. [18℄
Communi ations of the ACM, pages 966{975, Vol.
Invo ation Spe i ation, Revision 1.50, JDK 1.2.
21, N. 11, November 1978. Do umentation supplied with JDK 1.2 FCS, O t.
1998.
[8℄ Damien Doligez and Xavier Leroy. A on urrent,
generational garbage olle tor for a multithreaded [19℄ Luis Veiga and Paulo Ferreira. World wide news
implementation of ML. In Pro . of the 20th Annual gathering automati management. In 2nd Interna-
tional Conferen e Enterprise Information Systems,
ACM SIGPLAN-SIGACT Symp. on Prin iples of
Programming Lang., pages 113{123, Charleston SC
Staord, UK, July 2000.
(USA), January 1993. [20℄ Paul R. Wilson. Unipro essor garbage olle tion
[9℄ Paulo Ferreira and Mar Shapiro. Garbage ol- te hniques. In Pro . Int. Workshop on Mem-
ory Management, number 637 in Le ture Notes in
le tion and DSM onsisten y. In Pro . of the
First Symposium on Operating Systems Design and
Computer S ien e, Saint-Malo (Fran e), September
Implementation (OSDI), pages 229{241, Monterey
1992. Springer-Verlag.
CA (USA), November 1994. ACM. [21℄ V. Yong, J. Naughton, and J. Yu. Storage re lama-
[10℄ Paulo Ferreira and Mar Shapiro. Modelling a dis- tion and reorganization in lient-server persistent
tributed a hed store for garbage olle tion: the al- obje t stores. In Pro . Data Engineering Int. Conf.,
gorithm and its orre tness proof. In ECOOP'98, pages 120{133, Houston TX (USA), February 1994.
Pro . of the Eight European Conf. on Obje t- [22℄ Weimin Yu and Alan Cox. Conservative garbage
Oriented Programming , Brussels (Belgium), July olle tion on distributed shared memory systems.
1998. In 16th Int. Conf. on Distributed Computing Syst.,
[11℄ T. Le Sergent and B. Berthomieu. In remen- pages 402{410, Hong Kong, May 1996. IEEE Com-
tal multi-threaded garbage olle tion on virtually puter So iety.
shared memory ar hite tures. In Pro . Int. Work-
shop on Memory Management, number 637 in Le -
ture Notes in Computer S ien e, pages 179{199,