The OpenEdge Memory Profiler reports memory consumption for a specific ABL session, whether it is in a PAS for OpenEdge multi-session agent or a standalone ABL client process. Each ABL session may produce a large amount of data, which is written to a file. This data is then stored and processed in a database. The data is both:
  • Time-series—It reflects a sequence of snapshots of memory use over time.
  • Relational—Collected data is reported as delta changes between snapshots. Object memory usage information is only updated if it has changed since the previous snapshot. If an object appears once but is not referenced again, it likely means there were no further changes to that object, possibly up to and including its deletion or the program terminating. This helps maintain a relational view across snapshots while minimizing redundancy.
Together, these snapshots from a given ABL session comprise an ABL memory profiling recording. The OpenEdge Memory Profiler tool categorizes memory consumption by an ABL session into the following categories:
  • Platform memory—Includes memory consumption by essential components and processes necessary to run an ABL application. The following startup parameters may impact platform memory consumption:
    Note: Much of the platform’s memory usage is outside the control of the AVM, as it is dependent on the operating system. The following information is provided solely for reference purposes since their settings affect platform memory use.
    • -s stack to execute the ABL program
    • -Bt buffer size for temp-table database management
    • -mmax limit for memory used to manage r-code segments
    • -D directory entries to limit the number of separate r-code files to keep in memory
  • Application memory—Includes memory consumption by the objects that are created while running an ABL application. The following objects impact application memory consumption:
    • ABL (.p) procedure
    • User-defined OOABL class (.cls) that can be instantiated with NEW
    • Database connections
    • Dynamic objects (or Widgets)
    • Temp-tables
    • Widget-Pools
    • Handle-based objects such as SERVER, SOCKET, and memory pointers that are not created in a Widget Pool
    • Built-in OOABL objects
    • .NET objects
Note:
  • Only objects with instrumented types in the AVM are considered in the memory profile report.

  • You can enable memory profiling for AVM using the Profile Memory (-profileMemory) startup parameter, which is in effect until the ABL session is terminated.

    For more information, see Enable the AVM for memory profiling.

  • For a Progress Application Server (PAS) for OpenEdge instance, to understand how much memory is being used for a specific request, you need to measure memory usage at the start and end (boundaries) of that request. The application creates and destroys objects as needed over time. Since requests are expected to be stateless, these objects should not exist permanently and should only stay in memory for the duration they are required. It is important to let your application code run fully to the end of its intended process to properly identify potential memory leaks.