memory_strategy

Restriction: These tunables are supported for native COBOL only.

Syntax:

>>-----set memory_strategy-=-strategy-specification------><

Parameters:

strategy-specification

A numeric value representing one or more of the following flags (see Comments for information about valid combinations):

0x00000001: Check bytes strategy: prepend and append check bytes to each memory allocation
0x00000002: Check freed memory strategy: monitor for subsequent corruption the last n memory blocks freed, where n is the current value set using the memory_free_check_size run-time tunable
0x00000004: Reuse strategy: allow freed memory being monitored for corruption to be used to satisfy allocation requests
0x00000008: Validate strategy: validate memory before and after executing a user application running in a container
0x00000010: Validate strategy: validate memory before and after executing request handler functions in a container
0x20000000: Validate strategy: validate memory on the entry to and the exit from each program
0x40000000: Compatibility strategy: maintain compatibility with previous versions of the run-time system
0x80000000: Validate strategy: validate memory each time an allocation or free operation occurs

Properties:

Default:	0x40000000
IDE equivalent:	None Service Interfaces > Properties > Enterprise Server Run-time Configuration > Memory Management

Comments:

You can use this tunable to enable a process to be executed with one or more memory management strategies in place. For example, to specify that each memory allocation made by the run-time system is to have check bytes prepended and appended, and that each time an allocation or free operation takes place memory is to be validated, you would set the tunable as follows:

set memory_strategy=0x80000001

Only certain combinations of strategies are valid:

Check bytes, check freed memory, reuse and validate can be used together in any combination.
Compatibility can be used only with validate.

When the check bytes memory management strategy is in place, and the run-time system receives a request to free a memory block, the run-time system checks that the check bytes have not been corrupted, and then releases the memory. A corruption occurs when a program has written past the end of another memory block into the header of this one, or a program has written past the end of this memory block. If the run-time system detects a corruption, it issues run-time system error 252 indicating the memory block address and type of memory that has been corrupted, for example:

Execution error: file 'MYFILE'
error code: 252, pc=0, call=1, seg=0
252 Memory corruption detected (addr=00376068, type=136/1)

Note: The type is used by the run-time system for internal diagnostic purposes.

When the check freed memory strategy is in place, and the run-time system receives a request to free a memory block, the run-time system does not release the memory, but instead:

Clears the contents of the memory block to a predefined check value
Stores a reference to the block. The run-time tunable memory_free_check_size defines how many blocks the run-time system handles. If the limit has been reached, the run-time system:
1. Validates the contents of the memory pointed to by the oldest entry stored. If the validation fails (that is, the memory does not contain the expected check value), the run-time system issues run-time system error 252.
2. Frees the memory pointed to by the oldest entry stored.

You should use the check freed memory strategy with caution as it can lead to memory fragmentation and a significantly larger memory footprint for the process than would normally be expected.

You can use the reuse memory management strategy in conjunction with the check freed memory strategy to allow freed memory to be used to satisfy new allocation requests. When the reuse strategy is in effect and the run-time system needs to allocate a new block of memory, it first checks whether an area of freed memory will satisfy the allocation request. An allocation request will be satisfied from freed memory only if the size and type of the freed memory exactly match the size and type of the allocation request. When an allocation request is satisfied from freed memory, the run-time system first validates the contents of the freed memory. If the validation fails (that is, the memory does not contain the expected check value), the run-time system issues run-time system error 252.

The compatibility memory strategy is provided to give compatibility with the memory management provided in earlier versions of the run-time system. If this strategy is specified, all other strategies except validation are ignored. This strategy does not perform any memory validation or tracking, and silently ignores any memory chaining errors it encounters if an attempt is made to free a memory block more than once.

The validation memory management strategy causes all memory allocations previously made by the run-time system using the check bytes memory management strategy and all freed memory to be validated each time the run-time system is requested to perform a memory allocate or free operation. Additionally, if the operating system allows it, an operating-system memory heap validation check is performed. You should use this strategy with caution since it will lead to a major performance degradation in those applications that perform a large number of memory allocate and free operations.