Did this article resolve your question/issue?



What are the limitations of the ABL/AVM garbage collector?

« Go Back


TitleWhat are the limitations of the ABL/AVM garbage collector?
URL NameWhat-are-the-limitations-of-the-AVM-garbage-collector
Article Number000153463
EnvironmentProduct: OpenEdge
Version: 10.x,11.x
OS: All Supported Operating Systems
Other: .NETUI, GUI for .NET, Garbage Collection, OOABL
Question/Problem Description
What are the current limitations of the ABL/AVM garbage collector?

In which cases doesn't the ABL/AVM garbage collector delete unreferenced objects?
Steps to Reproduce
Clarifying Information
Garbage collection protects against memory leaks by automatically deleting class-based objects that are no longer referenced. For AppServer applications, garbage collection will run always before a switch in the connection context. Thus, AppServer applications running in all modes are protected by garbage collection.
Error Message
Defect/Enhancement NumberEnhancements PSC00231977, PSC00327793
AVM implements a Garbage Collector for ABL Classes. However, the implementation has some limitations: 

Class-based, ABL objects are either automatically deleted by the AVM during garbage collection when its reference count goes to zero, or manually deleted by the application using the DELETE 
OBJECT statement. 

Yet, garbage collection does not delete a class-based object with a circular reference. For example, Object A has a reference to Object B and Object B has a reference to Object A. To delete an object with a circular reference:

- Use DELETE OBJECT at least on one of the cross-referenced objects.
- Remove the circular reference by unreferencing one of the references (using ASSIGN object-reference = ?), to allow implicit deletion by the garbage collector. 

From the "Object oriented-programming" guide: Progress [...] recommends that you allow garbage collection to delete class-based objects whose reference counts are 0. You may want to use DELETE OBJECT for an object with a circular reference or for an object while references to it still exist.
Using DELETE OBJECT on an object that is referenced by another object will result in an invalid reference, requiring use of the ABL VALID-OBJECT() function. (Enhancement PSC00231977) 

We also maintain a reference to the class-based object if the object has a UI trigger, as the UI trigger could fire, executing behaviour in the object. Those type of objects are therefore not automatically garbage collected. This may change in future implemntations (Enhancement PSC00327793) 

Also, memory is not garbage collected automatically for Dynamic objects. Dynamic allocation is usually for objects whose size, quantity, or lifetime, could not be determined at compile-time. Memory is only allocated when the CREATE.... SET or RUN...... ASYNC statement executes. Therefore to avoid memory leak situations with dynamic objects use DELETE OBJECT, or widget pools.
References to other documentation:

OpenEdge Development: Object-oriented Programming, Chapter 2: "Getting Started with Classes, Interfaces and Objects" - Managing the object life-cycle.

Progress Article(s):

000017667, "Garbage collection issue - circular referencing object references not getting cleaned"
Last Modified Date10/30/2015 11:00 AM
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.