Restrictions and side-effects
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:
o A small increase (about 50 bytes) in the size of each message due to some DGC context information; and
o 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.
Last modified date: 04/20/2020