The OS allocates memory to a process in all sizes. The PAS for OpenEdge agent uses the malloc API to allocate all of its memory. Memory allocated using the malloc API is referred to as the Heap. Each process running in the OS has its own Heap.

The Heap represents the memory that is dynamically allocated by the process for its data needs, excluding the memory used to hold the executable image, shared libraries like .so/, .dll, the static data segment of the executable image, or the stack.

The Heap is managed by the malloc API, which serves the whole process for its dynamic memory allocation needs. The malloc API aims to achieve a balance between efficiency of time and efficiency of space by striving to be fast (time) and avoiding to use more than required (space) memory.

The following key points provide more information about Heap functionality:
  • The Heap can grow—The malloc API fulfills the demand for dynamic memory by managing the Heap. When required, it requests the OS to extend the Heap to acquire more memory to work with. Because this operation is expensive, the malloc API always tries to work within what is already available with the Heap.

    For example, if the PAS for OpenEdge agent supports 10 ABL sessions, each of which uses 50 MiB, then the Heap size will be approximately 0.5 GiB (50 MiB x 10 = 0.5 GiB). During peak load, if the PAS for OpenEdge agent starts five additional ABL sessions, then the malloc API ends up requesting the OS for more memory to extend the Heap.

  • The malloc API is affiliation agnostic between separate allocations—Because malloc API focuses on striking a balance between efficiency of time and space, it knows little about the purpose of any given memory request. Therefore, it does not necessarily group requests for memory for the same ABL session.
    For example:
    • When the Heap receives a request for 210 byte of memory, and it has a 256 bytes of memory chunk available from the OS, it may use the 256 byte chunk because it ends up wasting only 46 bytes of memory, which is better than taking extra time to search for an exact fit.
    • When the Heap receives a request to free 256 bytes of memory, and this chunk of memory is adjacent to another chunk of 256 bytes of memory, then the malloc API decides to either:
      • Consolidate the two chunks to create one large chunk of 512 bytes of memory. This operation takes time but creates a bigger chunk, which may be more useful.
      • Leave the two 256 byte chunks to be used seperately. This can lead to fragmentation of memory.

      The malloc API focuses on efficiency of time and space and does not necessarily group allocations for a common entity, like an ABL session, with one another. This can lead to the allocations for any given ABL session to be scattered somewhat randomly throughout the Heap.

Suppose the Heap of the PAS for OpenEdge agent grows from 0.5 GiB to 0.8 GiB, then you may assume that trimming some of the ABL sessions should reduce the memory footprint of the PAS for OpenEdge agent. In fact, it may, but usually it will not, because, in general, the malloc API can only release memory back to the OS if it is at the top of the Heap. If another ABL session is using memory which was allocated from near the top of the Heap, the malloc API can only release the memory above that point.

See Memory management in ABL for things you need to be aware of and techniques to use to ensure your application does not have memory leaks that may bring it to a halt when you put it into production.

The following exampleis an extremely simplified illustration of how Heap memory may become fragmented.
  1. Suppose a PAS for OpenEdge agent process has three ABL sessions, which have each allotted three segments from the Heap.

    The white segments represent free or unused memory.

  2. Now suppose that the PAS for OpenEdge agent requires an additional ABL session called AS-8 and the Heap does not have enough free memory to accommodate it. Thus, the malloc API will request that the OS extend the Heap.

    Observe that in addition to meeting the requirement of AS-8, both AS-4 and AS-7 also have additional needs and are allocated segments in the extended part of the Heap.

  3. The Administrator observes that the peak demand has reduced and decides to trim ABL session AS-7.

    In this case, the OS could reclaim the Heap memory if the actual memory used by ABL sessions AS-4, AS-6, and AS-8 were re-organized. Because the memory allocated by ABL sessions AS-8 and AS-4 are fixed in the extended Heap, the Heap extension cannot be returned to the OS. The Heap extension will remain in place as long as any allocation from it to other ABL sessions remains in it.

This example illustrates why Heap for a process generally only grows to meet the highest demand, but rarely shrinks back.