Allocation Strategy Type (CEE4ALC)
The CEE4ALC allocation strategy type contains attributes that are used to
define the characteristics of the storage allocated for heaps. ILE C defines
the attributes as shown in CEE4ALC Definition for ILE C. ILE COBOL defines
the attributes as shown in CEE4ALC Definition for ILE COBOL, and ILE RPG
defines the attributes as shown in CEE4ALC Definition for ILE RPG.
You can define an allocation strategy by altering the attributes of the
CEE4ALC allocation strategy type. You do this with the Define Heap Allocation
Strategy (CEE4DAS) API. Then, when you use the Create Heap (CEECRHP) API, you
can specify the allocation strategy that you defined for the heap attributes
you require.
If you use the CEECRHP API, but did not define an allocation strategy, a
default allocation strategy provides the heap attributes. See The Default Heap for a description of the default allocation
strategy.
Note: The creation size and extension size values of
CEE4ALC may be overridden. You do this by specifying values for the
initial_size parameter and the increment parameter on the CEECRHP bindable
API.
For ILE C the CEE4ALC allocation strategy type is defined as follows:
CEE4ALC Definition for ILE
C
struct _CEE4ALC {
_INT4 max_sngl_alloc; /* maximum size of a single allocation */
_INT4 min_ddy; /* minimum boundary alignment of any allocation */
_INT4 crt_size; /* initial creation size of the heap */
_INT4 ext_size; /* the extension size of the heap */
_INT2 reserved1; /* must be binary 0 */
_BITS alloc_strat:1; /* a choice for allocation strategy */
_BITS no_mark:1; /* a group deallocation choice */
_BITS blk_xfer:1; /* a choice for block transfer of a heap */
_BITS PAG:1; /* a choice for heap creation in a PAG */
/* The PAG option is ignored in i5/OS */
/* version 5 release 4 and later releases */
_BITS alloc_init:1; /* a choice for allocation initialization */
_UCHAR init_value; /* initialization value */
_BITS reserved2:3; /* must be binary 0 */
_BITS reserved3:32; /* must be binary 0 */
};
For ILE COBOL the CEE4ALC allocation strategy type is defined as
follows:
CEE4ALC Definition for ILE
COBOL
01 CEE4ALC-my-own.
05 max-sngl-alloc pic 9(9) BINARY.
05 min-bdy pic 9(9) BINARY.
05 crt-size pic 9(9) BINARY.
05 ext-size pic 9(9) BINARY.
05 reserved1 pic 9(4) BINARY VALUE 0.
05 my-bits pic x VALUE X"E8".
* Using initial value of X"E8" , alloc_strat, no_mark,
* blk_xfer, and alloc_init are set to TRUE
05 init-value pic x.
05 my-reserved2 pic x(5).
05 my-reserved3 pic x(5).
For ILE RPG the CEE4ALC allocation strategy type is defined as follows:
CEE4ALC Definition for ILE
RPG
D CEE4ALC DS
D MaxSglAloc 10I 0
D MinBdy 10I 0
D CrtSiz 10I 0
D ExtSiz 10I 0
D res1 5I 0
D AllocBits 1A
D InitValue 1A
D res2 5A
* Use BITON to set on the appropriate bit.
* For example BITON AllocInit AllocBits
D AllocStrat C '0'
D NoMark C '1'
D BlkXfer C '2'
D PAG C '3'
D AllocInit C '4'
- max_sngl_alloc
- The maximum allocation size, in bytes, of any single allocation from the
heap. This attribute is useful for controlling the use of the heap. The minimum
value for this attribute is 4 bytes, and the maximum value is 16MB minus 64KB.
If 0 is specified, the default value of 16MB minus 64KB is used.
- min_bdy
- The minimum boundary alignment, in bytes, associated with any allocation
from the heap. The minimum value for a boundary alignment is 4 bytes, and
maximum value is 512 bytes. To allow valid pointers to be stored in a storage
allocation with the heap, a minimum boundary alignment of 16 bytes is required.
If zero is specified, a default value of 16 bytes is used for the boundary
alignment. The minimum boundary alignment is rounded up to a power of 2.
- crt_size
- The creation size, in bytes, of the heap. The minimum value for the size of
the heap is 512 bytes and the maximum value is 16MB minus 1KB. If 0 is
specified, the system computes a default value. The value is rounded up to a
512-byte boundary.
Note: If system resources are constrained, the system may
override the value specified.
- ext_size
- The extension size of the heap in bytes. The minimum value for extension
size is 512 bytes and the maximum value is 16MB minus 1KB. If 0 is specified
the system computes a default value. The value is rounded up to a 512-byte
boundary.
Note: If system resources are constrained, the system may
override the value specified.
- reserved1
- Must be binary 0.
- alloc_strat
- Allows a choice between:
| 0 |
Normal allocation strategy. |
| 1 |
Create a process space on each allocation. |
Note: This option should be used only in unusual
situations, such as in debugging application problems caused by references past
the end of an allocation.
- no_mark
- Allows a choice between:
| 0 |
Allow the use of the CEEMKHP and CEERLHP
APIs. |
| 1 |
Do not allow the use of the CEEMKHP and CEERLHP
APIs. |
- blk_xfer
- Used to increase the
performance of a heap based on prior knowledge of how the heap is used.
The values are:
| 0 |
Transfer the minimum storage transfer size (that
is, 1 storage unit). |
| 1 |
Transfer the machine default storage transfer
size (that is, 8 storage units). |
Note: On the reduced instruction set computer (RISC)
hardware, this parameter has no effect. Regardless of whether 0 or 1 is
specified for blk_xfer, the machine default storage transfer size will always
be transferred.
- PAG
- A heap can be created as a process access group (PAG) member. The values
are:
| 0 |
Do not create the heap in the PAG. |
| 1 |
Create the heap in the PAG. |
Note: It is possible for the PAG to overflow, at which
point any requested PAG heap creations or extensions will not reside in the
PAG. Therefore, the system may ignore the request to create the heap in the
PAG.
Note:
The PAG option is ignored in i5/OS version 5 release 4 and later releases.
- alloc_init
- Allows the user to specify if all storage allocations from the heap being
created will be initialized to the initialization value. The values are:
| 0 |
Do not initialize the heap with Init_Value. |
| 1 |
Initialize the heap with Init_Value. |
- init_value
- The value used to initialize the storage allocations. This value is not
used if alloc_value is 0.
- reserved2
- Must be binary 0.
- reserved3
- Must be binary 0.
From the programmer's viewpoint, a default heap is always available in the
activation group. In fact, the first request to allocate storage results in the
creation of the default heap from which the storage allocation takes place.
The attributes of the default heap are defined by the system through a
default allocation strategy. You cannot change this default allocation
strategy. Following is an example of the default allocation strategy:
Max_Sngl_Alloc = 16MB - 64KB
Min_Bdy = 16
Crt_Size = 4KB
Ext_Size = 4KB
Alloc_Strat = 0
No_Mark = 1
Blk_Xfer = 0
PAG = 0
Alloc_Init = 0
Init_Value = 0x00 /* This value is not used */
/* if Alloc_Init is 0 */
In addition, the default heap in an activation group has the following
special characteristics:
- It may not be discarded by CEEDSHP (discard a heap); it is guaranteed to be
present for the life of the activation group.
- It is referred to with a heap identifier of 0.
Languages that do not have an intrinsic multiple-heap storage model (such as
ILE C) use the default heap. This heap cannot be discarded and is immune to the
Mark Heap (CEEMKHP) and Release Heap (CEERLHP) APIs. Storage allocated within
the default heap can be freed only by explicit free operations or when the
owning activation group ends.
This implementation ensures that the storage is not inadvertently released
in mixed-language applications. Release heap and discard heap operations are
considered insecure for the following reasons:
- Large applications that re-use existing code with potentially different
storage models.
- The programmer is not completely familiar with the internals of each
procedure.
If release heap operations were valid for the default heap, then procedures
that correctly use different storage management capabilities separately might
fail when used in combination.