How does ABL garbage collection work?
Garbage collection is an automatic system management feature whereby OOABL objects are destroyed when the count of other objects referring to them is zero.
- It only applies to OOABL objects including user-defined objects, system generated error objects, and .NET objects.
- Uses reference counting (counts all references of objects assigned to variables, or temp-tables).
- When reference count for an object goes to zero it is added to a list of 'objects to be destroyed'.
- System destroy objects at indeterminate intervals.
- Garbage collection on an AppServer will be run before the switch to a different context.
- If an object reference is defined with UNDO and is removed during a transaction, garbage collection will be postponed until the end of the transaction.
Why would preventing garbage collection from deleting objects be required?
For example, an application has a class acting as a singleton and it is necessary to ensure that the object is not deleted in the session.
1. Store in the object reference to itself:
CLASS nevergarbage:
DEFINE VARIABLE me AS Progress.Lang.Object.
CONSTRUCTOR PUBLIC nevergarbage():
me = THIS-OBJECT.
END.
END CLASS.
2. Have multiple objects referring to one another in a circular fashion.
3. Using the client startup parameter -nogc to disable garbage collection.
Troubleshooting:
The ABL profiler may show a statement taking longer to execute due to garbage collection.
Garbage collection does not force the Debugger to step into the destructor unless a breakpoint exists.
The ABL process has no control over when the .NET Garbage Collector does its work, How to force application garbage collection?
For further suggestions refer to Identifying and Troubleshooting Memory Leaks
