chapter 4 naming - 國立中興大學...chapter 4.1: naming entities o name: a string of bits or...

Chapter 4NamingHsung-Pin ChangDepartment of Computer ScienceNational Chung-Hsing University

Outlineo Naming Entities

o Locating Mobile Entities

o Removing Unreferenced Entities

Namingo In a DS, the implementation of a naming system is

itself often distributed across multiple machinesn How this distribution is done plays a key role in the

efficiency and scalability of the naming system

o The three main areas of study:1. The organisation and implementation of human-friendly

naming systems, e.g, WWW system.2. Naming as it relates to mobile entities.3. Garbage collection – what to do when a name is no longer

needed.

Chapter 4.1: Naming Entitieso Name: a string of bits or characters that is used to refer to an

entityo Entity – just about any resourceo Address – the name of an entity’s “access-point”.o Why not use address as an entity’s name

n An entity may change its access point in the course of timeo An access point may be reassigned to a different entity

n An entity can have more than one addresso A person can have more than one phone #

o Thus, a name is location independent is much easier to usen If it is independent from its addresses

o Furthermore, some types of names is human-friendly namesn Tailored to be used by humans and represented as character string

Identifiero A true identifier is a name with the following

propertiesn An ID refers to at most one entityn Each entity is referred to by at most one identifiern An ID always refers to the same entity (i.e., it is

never reused)o If an address can be reassigned, it cannot be used as

an ID

Name Spaceso Names are often organised into namespaceso A name space can be represented as a labeled,

directed graph with two types of nodesn leaf nodes: a named entity with no outgoing edgesn directory nodes: has a number of outgoing edges, each

labeled with a nameo Store a table called directory table: (edge label, node identifier)

o Each namespace has at least one root noden No incoming edge

Name Space Organizationo Could be a tree

n Each node except the root has exactly one incoming edgen Each node has exactly one associated (absolute) path name

o Could be a DAG (Directed Acyclic Graph)n A node may have more than one incoming edgen But not permit to have a cycle

o Could have a general graph structure (cycles permitted).n Each entity could have an infinite number of names

Name Spaces and Graphs

A general naming graph with a single root node. Note, this graph is a directed acyclic graph

Path Nameo Each path in the name space

N:<label-1, label-2, …, label-n>, where N is the first noden Absolute path name: N is a root noden relative path name: N is not rootn Similar to what used in typical file systems that the labels are

represented by a slash. E.g., /home/steen/mboxo global name: denotes the same entity no matter where the

name is usedo local name: name interpretation depends on where the name

is being usedo Example: an environment variable in UNIX is a local name

n E.g., HOME refer to the home directory of a user n Each user has its own copy of this variable, which is initialized to the

global user’s home directory

Name Resolutiono Given just the path name, the process of looking up

information stored in the node n And assuming, of course, that you know where to start …

o Closure mechanism: knowing how and where to start name resolutionn i.e., the mechanism to select the initial node from which

to start name resolution.n E.g. UNIX file system: root node is stored in a specific

place in the diskn E.g. 0031204447784: dial a phone number

Linko An alias is another name for the same entityo Two approaches to implement an aliasn Hard link approach: allow multiple absolute paths

names to refer to the same nodeo Both /keys and /home/steen/keys are called hard links to

node n5n Soft link or symbolic link approach: a node

containing the absolute path name of another node

Symbolic Link

The concept of a symbolic link explained in a naming graph.The node n5 has two names.

Mounto Name resolution can be used to merge different

name spaces in a transparent wayn Two approach: mount in NFS and GNS by DEC

o A mounted file system in NFSn Let a directory node store the identifier of a directory

node from a different name spacen Mount point: the directory node storing the node

identifiern Mounting point: the directory node in the foreign name

space

Mount (Cont.)n However, we need at least the following information

o The name of an access protocolo The name of the (foreign) servero The name of the mounting point in the foreign name space

n Represent the three names above as a URL used in NFSn E.g., a URL used in NFS (Network File System)

nfs://filts.cs.vu.nl/home/steeno Nfs: worldwide well-defined protocolo Server name (ilts.cs.vu.nl) is resolved by DNSo /home/steen is resolved by the server of the foreign name space

Mounting

Mounting remote name spaces through a specific process protocol (in this case Sun’s Network File System protocol - NFS).

Global Name Service (GNS)o Another way to merge different name spaceso By adding a new root node and making the existing

root nodes its childreno However, existing names need to be changed

n E.g., /home/steen is changed to /vu/home/steeno Thus, names in GNS always includes ID of the node

from where NR should startn E.g.: n0:/home/steen/keys

o After merge, the new root node has a mapping tablen no:/home/steebà (table lookup) à /vu/home/steen

DEC Global Name Service

Organization of the DEC “Global Name Service” (adds a new root node and makes existing root nodes its children).

The Implementation of a Name Spaceo A Name Service allows users and processes

to add, remove and lookup names.o Name services are implemented by Name

Serverso On LAN’s – a single server usually sufficeso On WAN’s – a distributed solution is often

more practical

The Implementation of a Name Space (Cont.)o Namespaces (and services) are usually organised

into one of three layerso Global Layer: highest level nodes

n Stable; dir tables change very infrequently. o Administrational Layer: directory nodes managed

by a single organisationn Relatively stable; although changes can occur more

frequently.o Managerial Layer: nodes change frequently

n Nodes maintained by users as well as administratorsn Nodes are the ‘leaf entities’ and can often change.

DNS Name Space Partition

An example partitioning of the DNS name space, including Internet-accessible files, into the three name space layers. A “zone” in DNS is a non-overlapping part of

the namespace that is implemented by a separate name server.

The Implementation of a Name Space (Cont.)o Availability and performance in each layer have

different requirementso Global layer and administrative layers

n Address the availability featureso If fail, a large part of the name space will be unreachableo Solution: replication and client caching

o In contrast, managerial layer address the performance, i.e., quick response timen Solution: local, high-performance name server

Name Server Comparison

SometimesYesYesIs client-side caching applied?

NoneNone or fewManyNumber of replicas

ImmediateImmediateLazyUpdate propagation

ImmediateMillisecondsSecondsResponsiveness to lookups

Vast numbersManyFewTotal number of nodes

DepartmentOrganizationWorldwideGeographical scale of network

ManagerialAdministrationalGlobalFeature/Characteristic

Comparing the features of name servers that implement nodes within a large-scale name space (partitioned into a global, administrational and managerial layer).

Availability and performance requirements are met by replication and caching at each of the various layers.

Name Resolution Processo Two Common Approaches

n Iterative name resolution.n Recursive name resolution

o Iterative name resolutionn e.g. root:<nl,vu,cs,ftp,pub,globe,index.txt>

o It URL notation: ftp://ftp.cs.vu.nl/pub/globe/index.txtn A name resolver in client hands over the complete name to the root

name servero Which resolves the path name as far as it can (nl) and returns the

resulting name server to the clientn The client passes the remaining path (/pub/globe/index.txt) to the

returned name servero Recursive name resolution

n A name server passes the result to the next name server

Iterative Name Resolution

The name resolver queries each name server (at each layer) in aniterative fashion. Note: the client is doing all the work here (and

generating a lot of traffic, too).

Recursive Name Resolution

The name resolver starts the process, then each server temporarily becomes a client of the next name server until the resolution is

satisfied. The results are then returned to the client.

Advantages and Disadvantageso Recursive name resolution

n Bad: puts a higher performance demand on each name server

n Good:o Caching is more effective compared to iterative name resolution

n One name server may cache the address of many of its lower-level name server (next slide)

o Communication cost may be reduced (next next slide)o Iterative name resolution

n Bad: caching is restricted to the client sideo If client A and B resolve the same name, caching in A is uselesso Sol: a local, intermediate name server shared by all clients under

its administration such that its cache is shared

Caching in Recursive Name Resolution

#<vu>#<vu,cs>#<vu,cs,ftp>

#<cs>#<cs,ftp>

#<ftp>

--

Receives and caches

#<nl>#<nl,vu>#<nl,vu,cs>#<nl,vu,cs,ftp>

<vu,cs,ftp>#<nl><ni,vu,cs,ftp>root

#<vu>#<vu,cs>#<vu,cs,ftp>

<cs,ftp>#<vu><vu,cs,ftp>ni

#<cs>#<cs, ftp>

<ftp>#<cs><cs,ftp>vu

#<ftp>--#<ftp><ftp>cs

Returns to requester

Passes to childLooks upShould

resolveServer for node

Recursive name resolution of <nl, vu, cs, ftp>. Name servers cache intermediate results for subsequent lookups. This is seen as a key advantage to the recursive name

resolution approach.

Communication Cost in Iterative vs. Recursive Resolution

The comparison between recursive and iterative name resolution with respect to communication costs. Again, the recursive

technology is generally regarded to have an advantage in this situation (especially over longer, more expensive WAN links).

www.cs.nchu.edu.tw

All name serversare in Taiwan

A machine in USA

Example: The Domain Name System(DNS)o One of the largest distributed naming services

n Used to lookup up host addresses and mail serverso DNS name space is organized as a rooted tree

n Each label (the bit between the ‘.’) must be < 64 charsn Each path (the whole thing) must be < 256 chars.n The root is given the name ‘.’ (although, in practice, the

dot is rarely shown nor required).n Example: flicts.cs.vu.nl. (root)

o A subtree within DNS is referred to as a “domain”.o A path name is referred to as a “domain name”.

n These can be relative or absolute.

Domain Name System (DNS) (Cont.)o The contents of a node is a collection of

resource recordsn SOA (start of authority): info such as email addr of the

system adminn A (address): IP addr of one of the hostn MX (mail exchange): a mail server in this domainn SRV (server name): the name of a server for a specific

service. o The service is identified by the name of a protocolo E.g. http.tcp.cs.un.nl: the web server in cs.vu.nl.

Domain Name System (DNS) (Cont.)n NS: the name of a name server for some a zonen CNAME: the canonical, or primary name of a aliasn PTR: do a "reverse" DNS lookup

o That is, they have your IP address and want to know what your host/domain is.

o But the name of the pointer record is not the IP address itself, but is the IP address’ four IP octets in reverse order followed by IN-ADDR.ARPA. n 192.168.0.1 becomes 1.0.168.192.IN-ADDR.ARPA.

n HINFO: store additional information on a hosto Machine type and operating system

n TXT: any other kind of data that is useful to user

DNS – Types of Resource Record

Contains any entity-specific information considered useful.Any kindTXT

Holds information on the host this node represents.HostHINFO

Contains the canonical name of a host.HostPTR

Symbolic link with the primary name of the represented node.NodeCNAME

Refers to a name server that implements the represented zone.ZoneNS

Refers to a server handling a specific service.DomainSRV

Refers to a mail server to handle mail addressed to this node.DomainMX

Contains an IP address of the host this node represents.HostA

Holds information on the represented zone.ZoneSOA

DescriptionAssociated entity

Type of record

The most important types of resource records forming the contents of nodes (and maintained by servers) in the DNS name space.

DNS Implementation Example

The DNS database for the zone cs.vu.nl. The “database”is a small collection of files

Three mail servers in this zone

This server has two NICs

DNS Example Explanationo Previous slide shows part of info in cs.vu.nl domain

n Node cs.vu.nl represents the domain as well as the zonen 3 name server in this zone with their priorityn star.cs.vu.nl is a name server with 2 IP address (2 NICs)n Zephyr.cs.vu.nl is a mail server, backed up by another mail

server tornado.cs.vu.nln Web server and http server are implemented at the same

machine

Example: X.500 Naming Serviceo A traditional naming service (like DNS) operates

very much like the Telephone Directory. n Find ‘B’, then find ‘Barry’, then find ‘Paul’, then get the

number.

o With a directory service, the client can look for an entity based on a description of its properties instead of its full name. This is more like the Yellow Pages.n Find ‘Perl Consultants’, obtain the list, search the list,

find ‘Paul Barry’, then get the number.

More on X.500o X.500: a directory service

n A client can look for an entity based on a description of properties instead of a full name

o X.500: a directory servicen Consist of a number of records, n A record is called a directory entryn Directory entries in X.500 are roughly equivalent to

domain names in DNS.n Each entry is a collection of (attribute, value)n A collection of directory entries is referred to as a

Directory Information Base (DIB).

The X.500 Name Space Example

130.37.21.11--WWW_Server

130.37.21.11--FTP_Server

130.37.24.6, 192.31.231,192.31.231.66--Mail_Servers

Main serverCNCommonName

Math. & Comp. Sc.OUOrganizationalUnit

Vrije UniversiteitLOrganization

AmsterdamLLocality

NLCCountry

ValueAbbr.Attribute

A simple example of a X.500 directory entry using X.500 naming conventions.

The X.500 Name Space Example (Cont.)o OrganizationUnit = department o Country and locality: where the entry is storedo A name attribute is also called Relative

Distinguished Name (RDN)n The first 5 attributes are all naming attributesn E.g. /C=TN/O=NTHU/OU=CSn Operation read and list are supported

o Read a single recordo List all records that match the search

More on X.500 (Cont.)o RDN’s can be arranged in sequence into a

Directory Information Tree (DIT).n See next slide

o The DIT is usually partitioned and distributed across several servers, which is called Directory Service Agents – DSA.

o Clients are known as Directory User Agents –DUA.

The X.500 DIT

Part of the X.500 Directory Information Tree (DIT)

More on X.500 (Cont.)o Implementation difference from DNSn The facilities for searching through a DIB

o E.g., answer = search (“&(C=NL)(O=VrijeUniversiteit)(OU=*)(CN=Mail Server)”)

n However, search in a directory service is an expensive operation

Chapter 4.2: Locating Mobile Entitieso Previous discussion assumes that naming entities

have fixed locationso How DNS works in a large-scaled DS

n Assume that moves occur rarely at the Global and Administrative layers,

n When moves occur at the Managerial layer, the entity stays within the same domain.

o Thus,n Look up addr of ftp.cs.vu.nl

o The client probably can find the addr of the name server for cs.vu.nl in its local cache

o One request to this name server solves the lookup

DNS Problem to Mobile Entitieso If ftp.cs.vu.nl moves to a different machine within the same domain

n Only DNS database of the name server for cs.vu.nl needs to be changedo Buf if ftp.cs.vu.nl moves to a machine in another domain, like

ftp.cs.unisa.edu.au?n The name ftp.cs.vu.nl preferably not change since there are many

symbolic links to itn Sol1: record the address of the new machine in DNS for cs.vu.nl

o Problem: if it moves again, the old DNS database needs to be updated, which is an expensive operation

n Sol2: record the name of new machine (i.e., ftp.cs.unisa.edu.au) in DNS for cs.vu.nlo Make ftp.cs.vu.nl into a symbolic linko Problems 1: each lookup is split into two steps

n Finding the name of the name machinen Look up the address associated with that name

o Problems 1: if it moves again, furthermore one more level of symbolic link

DNS Problem to Mobile Entities (Cont.)o Furthermore, both solutions have the same

problemn The name of ftp.cs.vu.nl. is not allowed to

changeo In summary, traditional naming services (such

as DNS) cannot cope well with mobile entitiesn Since DNS maintains a direct mapping between

names and addresses

Naming vs. Location Services

a) Direct, single-level mapping between names and addresses.b) Two-level mapping using a “location service”.

Better Solutionso Introduce identifiers to separate naming from

locating entitieso Locating an entity is handled by a separate

location servicen Accept identifier and return the current address of

the entityo If multiple copies exist, return multiple addresses

o Thus, we now have three types of namesn Human-friendly names, identifiers, and addresses

Solution to Local Serviceo Simple solutions: both solutions below are

applicable only to local area networksn Broadcasting and multicastingn Forwarding Pointers

o Home-based approaches

o Hierarchical approaches

Simple Solutions #1: Broadcasting and Multicastingo Broadcast “where are you?” packets to each

machinen Each machine checks if it has the entity

o ARP (Address Resolution Protocol) uses this methodn IP address broadcasting à return data-link addr

o Improvement: multicasting to a group of machines

Simple Solutions #2: Forwarding Pointerso When an entity moves from A to B, it leaves

in A a reference to Bo Example: SSP chainsn A forwarding pointer consists (proxy, skeleton)

o Proxy: client-side stubn link to a skeleton in another machine

o Skeleton: server-side stubn Either to the actual object or to a proxy

Forwarding Pointers

(1)

(2)

o An object moves from A to Bn Leaves a proxy in An Install a skeleton in B that refers to the object

Disadvantages of Forwarding Pointerso A chain can become very long

n The “lookup” eventually becomes prohibitively expensive.n Improvement: short cut forward chains

o Sending response directly to the initiating proxy or along the reverse path

o All the “intermediate locations” must maintain their chains for “as long as needed”n However long that is

o Big vulnerability: broken links. n Break a link and a forwarded entity is lost.

Short-Cut Forwarding Chain

Redirecting a forwarding pointer by storing a shortcut in a proxy.

Solution #3: Home-Based Approacheso Home-based approach

n A home location keeps track of the current location of an entityn This home can be contacted in order to determine the mobile entities

current location.o Example: Mobile IP

n Each mobile host uses a fixed IP addresso All comm to that IP add is directly to its home agento Mobile host use a care-of address when it moves to another networko The care-of address is registered to the home agent

o Drawbacksn Increased latency, especially when host and home are far apartn Permanent moves

Home-Based Approaches

Solution #4: Hierarchical Approacheso A network is divided into a collection of domains

o Tree-like, or DNS-like domain structure (next slide)

o Each domain has a directory node that keeps track of all entities in that domainn An entity currently located in domain D is represented by a

location record in the directory node dir(D)o Keep the entity’s current address

Hierarchical Approaches

Hierarchical organization of a location service into domains, each having an associated directory node

Hierarchical Approaches (Cont.)o A higher domain dir node will have, for each entity,

an location record containing a link to a child domain’s dir node

o Thus, the root node has a location record for each entity

o If an entity is duplicated, (say in D1 and D2), then the dir node of the smallest domain containing both D1 and D2 will have two pointersn One for each subdomain (next next slide)

Replicated Entities

Hierarchical Approaches (Cont.)o Lookup operation is forwarded from a leaf domain

to a higher level domain (next slide)o The lookup operation exploits localityo Update operations also exploits locality (next next

slide)n However, the chain of pointers can be constructed from

the bottom upo i.e., create a location record before passing the insert request to

the parent noden Adv. an address becomes available for lookups as soon as

possible

Lookup Operation

Update OperationsNote: update is stopped at M and do

not need to propagate to root dir.

(a) An insert request is forwarded to the first node that knows about entity E(b) A chain of forwarding pointers to the leaf node is created

Pointer Cacheso Cache is useless to mobile entity-> Sol. Pointer

cacheso If D is the smallest domain in which a mobile entity

E moves regularlyn We better start a lookup for E at directory node dir(D)n Each domain’s dir node stores a pointer to dir(D) for

entity Eo Further improvement: dir(D) can store the addr of E

directly, instead of pointer to its sub-domainn A lookup operation can be realized in only two steps

Pointer Caches (Cont.)o Discussion: how to find the best dir node to

store the current addr of E?n It is not easy to determine the smallest domain

o Discussion: when to invalidate a cache entry?n e.g. when a replica is created, it is better to use

the nearby replica, instead of the remote E’s entity (next slide)

Pointer Caches

Caching a reference to a directory node of the lowest-level domain in which an entity will reside most of the time.

Pointer Caches with Replicated Entity

A cache entry that needs to be invalidated because it returns a nonlocal address, while such an address is available.

Scalability Issueso Root node is required to store a location record for

each entity n May require to handle so many lookup and update

requestsn Becomes a bottleneck

o Sol: partition the root node and other high-level directory nodes into subnodesn Partition physically, like COW or MPPn Spread the subnodes uniformly across the network

o But how to decide which subnode should handle which entities in a very large-scale location service is an open question

Scalability Issues with the Hierarchy Approach

The scalability issues related to uniformly placing subnodes of a partitioned root node across the network covered by a location service.

Chapter 4.3: Removing Unreferenced Entitieso Removing unreferenced entities can be tricky.

o As soon as a entity is no longer required, it (and any copies of it and/or references/pointers to it) needs to be removed from the distributed system.

o For an example of this type of problem, just look at the mess of unreferenced HTML documents (“broken links”) on today’s Internet

Removing Unreferenced Entitieso Managing the removal of entities in a distributed

system is often difficultn An unreferenced entity is no longer needed and should be

removed from the DSn However, having a remote reference to an object does not

mean that object will ever be accessedo Two references may each store a reference to the other but are not

referenced at all (forming a “cycle”)

o Distributed garbage collectorsn Automatically remove an entity when it is no longer needed

Unreferenced Objects

An example of a graph representing objects containing references to each other.

Represent a systemwideservice, a user and so on

Simple Reference Countingo Increment and decrement the counter as referenced or

dereferencedo Problem 1: unreliable communications systems

n Create a reference and remove a reference will cause problem if communication is error

o Problem 2: copying a remote reference to another machine (next next slide)n A race condition in incrementing and decrementing, shown in (a)n Sol: first inform the object skeleton

o The remote process is allowed to decrement its count only after it receives confirmation from the skeleton

n Drawbacks: cause three messages in reference passing

Reference Counting Problem

The problem of maintaining a proper reference count when adding a reference but in the presence of unreliable communication.

retransmission

Reference Passing

(a) Copying a reference to another process and incrementing the counter too late(b) A solution.

Advanced Reference Countingo Previous simple reference counting impose a race

condition between incrementing and decrementingo Sol. Only use decrement operationso Weight reference counting

n Each object has a fixed total weight and a partial weightstored in its skeletono Partial weight is initialized to equal to the total weight

n If a new remote reference is created, half of the partial weight is reassigned to the new proxy

n If a reference is destroyed, its partial weight is subtracted from the total weight

n If total weight = 0, the object is removed

Weighted Referencing Counting

(a) The initial assignment of weights in weighted reference counting(b) Weight assignment when creating a new reference.

Weighted Referencing Counting

(c) Weight assignment when copying a reference.

Weighted Referencing Counting (Cont.)o Problem: weight reference counting allows only a

limited # of references to be createdn Until the partial weight drops to zero

o Solutions: indirection

Creating an indirection when the partial weight of a reference has reached 1.

Generation Reference Countingo An alternative to avoid using indirection

n Since long chains seriously degrade performanceo An object has only one skeleton

n It maintains a table G[i], denoting the # of outstanding copies for generation i

o Each proxy has 2 countersn Copy: # of times the proxy has been copiedn Generation: increment by 1 in the remote proxy that has just been

copiedo When copying a remote reference from P1 to P2

n P1: copy counter + 1n P2: generation number = generation number[P1] + 1, copy

number = 9

Generation Reference Counting

Creating and copying a remote reference in generation reference counting.

Generation Reference Counting (Cont.)o The skeleton maintain a table Gn G[i]= number of copies for generation i

o Approaches if a proxy p is removedn Assume p’s generation = k, p’s copy counter = nn G[k] = G[k] – 1n G[k+1] = G[k+1] + nn If G[k] = 0, for any k, the object can be removed

Reference Listingo Reference Listing:

n let a skeleton keep track of all proxies referencing to itn Instead maintaining an reference count

o Messages of adding and removing proxy can be repeated without side-effectsn If a proxy is already in the list, adding it again does not change the list. n If a proxy is not in the list, removing it from the list does not change the list.

o Reference Listing is said to be “idempotent”n An operation can be repeated any number of times without affecting the end

result. n So a proxy can keep adding/removing itself from the list until an ACK is

returned. n However, increment and decrement are not idempotent

o Key point: duplicates are OK, and reliable communications is NOT required.

Reference Listingo Easy to keep the reference list consist in the face of

process failuresn Skeleton regularly pings each proxy to remove unechoed

proxieso Drawback:

n May scale badly if the skeleton needs to keep track of many references

n Sol. Timeout or lease mechanismo A reference is valid for a limited time and will be removed if it

does not renew its registration before timeout

Identifying Unreachable Entitieso Above approaches cannot deal with isolated cycle

references n Sol: tracing-based garbage collection

o In Uniprocessor : mark-and-sweep by 3 coloring markingn Mark: Initially white, in-progress gray, completed black

o Gray is used to keep track of the progress being madeo An entity is marked gray when it is found to be reachable but the

references stored by that entity need yet to be inspected

n Sweep: Reclaim white objects

Identifying Unreachable Entitieso In DS: similar 3 coloring approachn Follow proxy->skeleton link to trace all objects

o Drawbacks: n All systems need to be synchronized stopped

during garbage collection o Since the reachability graph should be remained the

same during both phaseso Also called stop-the-world synchronization

Tracing in Groupso For scalability, collect all garbage within each group

concurrentlyn Group: a collection of processes

o It takes 5 steps in a groupn 1. Initialing marking on skeletonsn 2. intraprocess propagation from skeletons to proxies

o Local propagationn 3. Interprocess propagation from proxies to skeletonsn 4. Stabilization by repetition of the previous two stepsn 5. Garbage reclamation

1st: Initialing Marking on Skeletonso Assume each skeleton maintains a reference countero Count the number of proxies associated with the

skeleton that are outside the same groupn If zero: softn If greater than zero: hard

o A skeleton can be marked as soft or hardn Soft: reachable only from proxies inside the groupn Hard: reachable from a proxy outside the group

Initial Marking of Skeleton

2nd: Local Propagationo Local Propagation: intraprocess propagation marks from

skeletons to proxieso First

n All proxies are marked nonoo Then

n Start from set of skeletons that have been previously marked hardo Hard mark are propagated to all objects reachable from this set

n And from the object in the root seto Finally

n From skeletons that marked softo The reachable proxies are also marked soft

Local Propagation

After local propagation in each process.

3rd: Interprocess Propagation from Proxies to Skeletonso Marks are propagated between processes

o If a proxy is marked hardn Its associated skeleton are also marked hard

4th: Stabilization by Repetition of the Previous Two Stepso Global propagation of hard marks in the

previous step

Final Marking

Final marking.

5th: Garbage reclamationo Remove unreachable objectsn Unreachable proxiesn Proxies and skeletons that have been marked soft

o Since they are not reachable from outside the group nor are they reachable from objects in a root set

o i.e., soft marked proxies and skeletons refer only to each other