![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Memory Management (Package V_Memory) This section contains an overview describing this package. This overview section is followed by a detailed description of each subprogram in this package.
The following topics are covered in this section:
Package OverviewDescription
package V_Memory provides memory management operations through three distinct methods: FixedPools, FlexPools, and HeapPools.
For each type of pool, operations are provided to enable creation, deletion, allocation, and deallocation (with the exception that deallocation is not provided for HeapPools). The allocation and deallocation operations are implemented as generics that can be instantiated to create allocators and deallocators for a given type of object for a given type of pool.
FixedPools are made up of constant-sized memory blocks, providing fast allocation and deallocation with constant time overheads. Fixed memory pools are best suited for storage of objects of relatively homogeneous size.
FlexPools contain variably-sized memory blocks, providing efficient use of memory. The problem of fragmentation, inherent in variably-sized allocation schemes, is diminished by the VADS Exec concept of granularity, whereby blocks are allocated on specified boundaries. FlexPools are organized around a standard boundary tag scheme, providing for compaction of adjacent blocks.
HeapPools provide the fastest memory allocation in VADS Exec. There is no deallocation of heap memory and therefore no space overhead in managing the pool and minimal processing overhead in allocating from a heap. HeapPools are intended for circumstances where a pool of memory is required for a short period of time. After use, the entire pool can be deleted.
Although memory for pool usage is allocated from a fixed address by default, you can also allocate memory from a dynamic address. Simply perform an Ada new allocation and use this allocation as the starting address for the pool.
The maximum number of pools that can exist at any given time is limited to 20. This limit applies only to package V_Memory.
Package Procedures and Functions
Table 9 lists the procedures and functions in package V_Memory with a brief description of each subprogram.
Types
Table 10 lists the types in package V_Memory.
Exceptions
Table 11 lists the exceptions in package V_Memory.
Package Specification
with V_I_Mem; with System; package V_Memory is pragma SUPPRESS(ALL_Checks); type fixed_pool_id is private; type flex_pool_id is private; type heap_pool_id is private; Bad_Pool_Creation_Parameter : exception; NO_AVAILABLE_Pool : exception; INVALID_Pool_ID : exception; NO_Memory : exception; BAD_BLOCK : exception; Object_LARGER_THAN_FIXED_BLOCK_SIZE : exception; UNCONSTRAINED_Object : exception; UNEXPECTED_V_Memory_ERROR : exception; procedure Initialize_Services (top_of_Memory : in system.address := system."+"(16#FFFF_FFFF#); machine_boundary : in integer := integer'size; granularity : in integer := 16 ); pragma Inline_Only(Initialize_Services); procedure Create_FIXED_Pool (base_address : in system.address; pool_size : in natural; block_size : in natural; pool : out fixed_pool_id); pragma Inline_Only(Create_FIXED_Pool);
generic type Object is private; type POINTER is access Object; function FIXED_Object_ALLOCATION (pool : in fixed_pool_id; value : in object) return pointer; -- pragma Inline(FIXED_Object_ALLOCATION);
generic type Object is private; type POINTER is access Object; procedure FIXED_Object_DEALLOCATION (location : in pointer); -- pragma Inline(FIXED_Object_DEALLOCATION);
procedure Destroy_FIXED_Pool (pool : in fixed_pool_id); pragma Inline_Only(Destroy_FIXED_Pool);
procedure Create_FLEX_Pool (base_address : in system.address; pool_size : in natural; pool : out flex_pool_id); pragma Inline_Only(Create_FLEX_Pool); generic type Object is private; type POINTER is access Object; function FLEX_Object_ALLOCATION (pool : in flex_pool_id; value : in object) return pointer; -- pragma Inline(FLEX_Object_ALLOCATION);
generic type Object is private; type POINTER is access Object; procedure FLEX_Object_DEALLOCATION (location : in pointer); -- pragma Inline(FLEX_Object_DEALLOCATION); procedure Destroy_FLEX_Pool (pool : in flex_pool_id); pragma Inline_Only(Destroy_FLEX_Pool);
procedure Create_Heap_Pool (base_address : in system.address; pool_size : in natural; pool : out heap_pool_id); pragma Inline_Only(Create_Heap_Pool);
generic type Object is private; type POINTER is access Object; function Heap_Object_Allocation (pool : in heap_pool_id; value : in object) return pointer; -- pragma Inline(Heap_Object_Allocation);
procedure Destroy_Heap_Pool (pool : in heap_pool_id); pragma Inline_Only(Destroy_Heap_Pool); private type fixed_pool_id is new V_I_Mem.pool_id; type flex_pool_id is new V_I_Mem.pool_id; type heap_pool_id is new V_I_Mem.pool_id; end V_Memory;
Procedures and Functions in Package V_Memoryprocedure Create_Fixed_Pool
Syntax
procedure Create_Fixed_Pool (base_address : in system.address; pool_size : in natural; block_size : in natural; pool : out fixed_pool_id); pragma Inline_Only(Create_Fixed_Pool);Arguments
- base_address
Address at which the pool starts.
- block_size
Size of each block, in bytes, in the pool.
- pool
Identifier associated with the created pool.
- pool_size
Description
Upon creation, the pool is subdivided into blocks. Each block is of the size specified by the block_size parameter. Each block is preceded by a 20-byte (for 32-bit systems) or 32-byte (for 64-bit systems) header that contains information used to manage the pool.
Thus, a 16#10_000# byte pool of 16#400# byte blocks provides 62 blocks with 1240 bytes (32-bit systems) or 1984 bytes (64-bit systems) used for headers.
Exceptions
- Bad_Pool_Creation_Parameter
A pool creation parameter is invalid.
- No_Available_Pool
The maximum number of pools that can exist simultaneously in the system has already been allocated.
procedure Create_Flex_Pool
Syntax
procedure Create_Flex_Pool (base_address : in system.address; pool_size : in natural; pool : out flex_pool_id); pragma Inline_Only(Create_Flex_Pool);Arguments
- base_address
Address at which the pool starts.
- pool
Identifier associated with the created pool.
- pool_size
Description
Each block in a FlexPool requires 28 bytes (32-bit systems) or 44 bytes (64-bit systems) of overhead for pool management. Upon creation, blocks are created at the front and back of the pool to simplify the pool management operations. Because these are null blocks, they consume a total of 56 bytes (32-bit systems) or 88 bytes (64-bit systems).
Thus, after creation, a 1000-byte pool contains a 916-byte block (32-bit systems) or an 868-byte block (64-bit systems). Subsequent allocations split this block into smaller blocks.
Exceptions
- Bad_Pool_Creation_Parameter
A pool creation parameter is invalid.
- No_Available_Pool
The maximum number of pools that can exist simultaneously in the system has already been allocated.
procedure Create_Heap_Pool
Syntax
procedure Create_Heap_Pool (base_address : in system.address; pool_size : in natural; pool : out heap_pool_id); pragma Inline_Only(Create_Heap_Pool);Arguments
- base_address
Address at which the pool starts.
- pool
Identifier associated with the created pool.
- pool_size
Description
No internal management is performed on HeapPools and thus no memory within the pool is reserved for pool management. A 1000-byte pool provides 1000 bytes of available memory.
Exceptions
- Bad_Pool_Creation_Parameter
A pool creation parameter is invalid.
- No_Available_Pool
The maximum number of pools that can exist simultaneously in the system has already been allocated.
procedure Destroy_Fixed_Pool
Syntax
procedure Destroy_Fixed_Pool (pool:in fixed_pool_id); pragma Inline_Only(Destroy_Fixed_Pool);
Arguments
Exceptions
procedure Destroy_Flex_Pool
Syntax
procedure Destroy_Flex_Pool(pool : in flex_pool_id); pragma Inline_Only(Destroy_Flex_Pool);Arguments
Exceptions
procedure Destroy_Heap_Pool
Syntax
procedure Destroy_Heap_Pool(pool: in heap_pool_id); pragma Inline_Only(Destroy_Heap_Pool);
Arguments
Exceptions
generic function Fixed_Object_Allocation
Syntax
generic type Object is private; type Pointer is access Object; function Fixed_Object_Allocation (pool : in fixed_pool_id; value : in object) return pointer;Arguments
Description
Fixed_Object_Allocation allocates an object of type object from a specified FixedPool, initializing it with the specified value. Multiple instantiations of Fixed_Object_Allocation can use the same fixed pool.
Exceptions
- Invalid_Pool_ID
pool does not identify a FixedPool.
- No_Memory
The object cannot be allocated from the pool because of insufficient memory.
- Object_Larger_Than_Fixed_Block_Size
The size of the object exceeds the size of the pool blocks.
- Unconstrained_Object
The generic is instantiated with an unconstrained object type.
generic procedure Fixed_Object_Deallocation
Syntax
generic type Object is private; type POINTER is access Object; procedure FLEX_Object_DEALLOCATION (location : in pointer);Arguments
Description
Fixed_Object_Deallocation deallocates memory at the given location.
Exceptions
generic function Flex_Object_Allocation
Syntax
generic type Object is private; type POINTER is access Object; function FLEX_Object_ALLOCATION (pool : in flex_pool_id; value : in object) return pointer;Arguments
Description
Flex_Object_Allocation allocates an object of type object from a specified FlexPool, initializing it with the specified value.
The object is allocated from the pool using a first-fit algorithm. If, after taking into account the pool granularity, enough unused memory in the selected block exists to create a new block, the block is split into two blocks.
Exceptions
- Invalid_Pool_ID
pool does not identify a FlexPool.
- No_Memory
The object cannot be allocated from the pool because of insufficient memory.
- Unconstrained_Object
The generic is instantiated with an unconstrained object type.
generic procedure Flex_Object_Deallocation
Syntax
generic type Object is private; type POINTER is access Object; procedure FLEX_Object_DEALLOCATION (location: in pointer);
Arguments
Description
This procedure combines the deallocated block with any adjoining free blocks to form a single, larger free block.
Exceptions
generic function Heap_Object_Allocation
Syntax
generic type Object is private; type POINTER is access Object; function Heap_Object_Allocation (pool : in heap_pool_id; value : in object) return pointer;Arguments
Description
Heap_Object_Allocation allocates an object of type object from a specified HeapPool, initializing it with the specified value. Heap objects are allocated through the use of a pointer, which indicates the next available block and the number of bytes available.
Exceptions
- Invalid_Pool_ID
pool does not identify a HeapPool.
- No_Memory
The object cannot be allocated from the pool because of insufficient memory.
- Unconstrained_Object
The generic is instantiated with an unconstrained object type.
procedure Initialize_Services
Syntax
procedure Initialize_Services -- 32 bit systems (top_of_Memory : in system.address := system."+"(16#FFFF_FFFF#); machine_boundary : in integer := integer'size; granularity : in integer := 16); pragma Inline_Only(Initialize_Services); procedure Initialize_Services -- 64 bit systems (top_of_Memory : in system.address := system."+"(16#FFFF_FFFF_FFFF_FFFF#); machine_boundary : in integer := integer'size; granularity : in integer := 16); pragma Inline_Only(Initialize_Services);Arguments
- granularity
Controls memory fragmentation within the flex memory pools.
- machine_boundary
- top_of_Memory
Highest memory location addressable by the target/host (default value = 16#FFFF_FFFF# (32-bit systems) or 16#FFFF_FFFF_FFFF_FFFF (64-bit systems))
Description
The procedure Initialize_Services initializes memory services by supplying them with top-of-memory, machine boundary, and granularity information. The machine_boundary parameter is particularly important on machines that impose specific bit alignment for certain data types. For Initialize_Services, the machine_boundary parameter defaults to Integer'Size.
Within the Initialize_Services procedure, the granularity parameter controls flexpool memory fragmentation. Flex pools provide storage in blocks of various sizes, differing in bytes, causing all allocation requests to be rounded to the nearest multiple of 16. Unless specified otherwise, Initialize_Services defaults the granularity to 16.
Initialize_Services must be called before any of the memory services. The V_Memory package body calls Initialize_Services, using the default parameter values. Consequently, you must call Initialize_Services only when you want to override the default parameters.
The top_of_Memory parameter is used to validate the Base_Address parameter for the Create_Fixed_Pool, Create_Flex_Pool, and Create_Heap_Pool services. The default value of 16#FFFF_FFFF# (32-bit) or 16#FFFF_FFFF_FFFF-FFFF#(64-bit) ensures that any Base_Address parameter is valid.
Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2003, Rational Software Corporation. All rights reserved. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |