Server Smalltalk Guide
There are a number of restrictions and side-effects to the operation of
the DGC system which are important to note.
- Note all of the requirements listed in Requirements for using DGC.
- There is no requirement for DGC to be installed in all application
contexts participating in some distributed application. Similarly, it
is possible to have multiple DGC systems executing concurrently provided that
the subset spaces of the participating contexts do not overlap.
-
- Spaces which do not participate in DGC but communicate with spaces which
do may lose access to remote objects they reference if those objects are
garbage collected. It is advisable to start up the DGC system in all
participating spaces before any significant amount of inter-space
communication occurs and to shut down the DGC system in a space only after it
no longer needs any remote references it may have.
- Distributed garbage cycles are not collected. For example, assume
object foo in space A references object bar in space B, and vice versa.
Even if there are no other references to either foo or bar, they form a
distributed cycle and will not be detected as garbage.
- A modifiable copy of the configuration is made when instantiating the
SstDgcConfiguration object. Thus, modification of
configuration options after the DGC object has been created must be performed
on the configuration accessed from the SstDgc object, not the
original.
- DGC must be instantiated and started up in the application context which
manages the DGC coordinator space. If this does not occur, registration
attempts will eventually cease and no collection will be performed.
- SST does not permit communication between spaces belonging to logically
different distributed application contexts. Thus if application
contexts C1 and C2 are installed in some SST image, DGC cannot be installed to
operate across both C1 and C2.
- The DGC system has not been tested with unordered network communications
(those for which there is no guarantee that two communications between two
machines are received in order). Although the design is reasonably
resilient to asynchronicity, there may be unexpected behavior in the DGC
system.
- DGC impacts performance in two ways:
- A small increase (about 50 bytes) in the size of each message due to some
DGC context information; and
- An increase in message traffic during collection iterations. Each
iteration requires at least three coordinator-to-all messages plus at least
one message between each space importing an object and the space hosting that
object. Additionally, there are some minimal memory requirements for
the DGC objects and processing overheads associated with the operation of the
DGC system.
[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]