While OpenEdge loads r-code, all of its segments are locked in memory. After all required segments are loaded from the r-code, OpenEdge unlocks all segments except its main action code segments and text segment. These segments stay locked in memory until execution of the r-code terminates. Internal procedure action code segments stay locked only until they return to the invoking procedure and are relocked each time they execute.
When a standard r-code segment does not fit in the execution buffer, OpenEdge attempts to free space by swapping r-code segments already in the buffer to the r-code swap file. OpenEdge can swap out any unlocked segments and then remove these segments from the tail end of the execution buffer chain, in least recently used (LRU) order.
If OpenEdge cannot free enough memory for a newly loaded segment by swapping out older segments, it dynamically increases the maximum execution buffer size (execution buffer ceiling) and allocates the required memory up to the memory available.
When OpenEdge needs a segment that has been swapped to the r-code swap file, it reloads the segment from the swap file into the execution buffer. However, OpenEdge keeps the reloaded segments in the swap file.
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. When accessing members stored in a standard library, OpenEdge does not swap r-code segments to the r-code swap file unless you specify the PROLIB Swap (-pls) startup parameter. By default, if OpenEdge needs an r-code segment in a standard library, it reloads the segment into the execution buffer from the library in local memory.
