At run time, OpenEdge manages the execution of memory-mapped r-code using the following components:

  • Shared memory buffer — The portion of shared memory that the operating system allocates and uses to store r-code segments for members in a memory-mapped procedure library
  • Segment descriptor table — An in-memory table that references the r-code segments required by all executing members, including the location of each r-code segment in memory and usage count information
  • R-code directory — An in-memory table that contains information about each executing member, including r-code size, usage count, segment descriptions, and a reference to the segment descriptor table for each segment

OpenEdge uses the segment descriptor table and the r-code directory to manage r-code from operating system files, standard procedure libraries, and memory-mapped procedure libraries.

The following image shows the layout for the memory-mapped r-code execution environment.

Figure 1. Memory-mapped r-code execution environment


In the above image, OpenEdge locates the cust.r and orders.r members in a memory-mapped procedure library. Note that all r-code segments in a memory-mapped procedure library are located in shared memory. When OpenEdge needs a segment, it executes the segment directly from shared memory.

Memory-mapped execution sequence

When you run a memory-mapped member for the first time, OpenEdge loads and executes the r-code as follows:

  1. Opens the procedure library, if not already open, and memory-maps the library in shared memory.
  2. Reads the member and creates an r-code directory entry for the member.
  3. Registers each required r-code segment in the execution environment as follows:
    1. Adds an r-code segment entry to the segment descriptor table that references the segment in shared memory.
    2. Inserts a segment descriptor reference in the r-code directory entry for the member.
  4. Once the required r-code segments are registered in the execution environment, the interpreter begins executing the r-code at the start of the first main action code segment and accesses the remaining segments directly from shared memory as required.

Memory-mapped execution environment limits

The amount of memory-mapped r-code that you can run at one time and how much shared memory it uses are determined by the following factors:

  • R-code directory size — The default is 100 entries, the minimum is five entries, and the maximum is 2,147,483,647. You can set the initial number of entries using the Directory Size (-D) startup parameter. OpenEdge dynamically increases the directory size up to the maximum, as required. Use the Hardlimit (-hardlimit) startup parameter to force OpenEdge to adhere to the limit specified by the Directory Size (-D) startup parameter.
  • Available memory — The number of memory-mapped procedure libraries you can have open is limited by the amount of shared memory available on the system.

Memory-mapped r-code segment management

When OpenEdge needs a memory-mapped r-code segment, it executes the segment directly from shared memory. OpenEdge does not store active memory-mapped r-code segments in the execution buffer. Nor does it swap non-active segments to the r-code swap file. OpenEdge relies on the operating system to manage the swapping of r-code segments in and out of shared memory.

Note: The AVM swaps codepage-converted text segments for procedure libraries from the execution buffer to the r-code swap file and reloads the converted text segments from the swap file instead of the library when necessary.