TOC PREV NEXT INDEX DOC LIST MASTER INDEX



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 Overview

Description

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.

Table 9 Procedures and Functions
Name
Description
procedure Create_Fixed_Pool
Create a FixedPool.
procedure Create_Flex_Pool
Create a FlexPool.
procedure Create_Heap_Pool
Create a HeapPool.
procedure Destroy_Fixed_Pool
Delete a FixedPool.
procedure Destroy_Flex_Pool
Delete a FlexPool.
procedure Destroy_Heap_Pool
Delete a HeapPool.
generic function Fixed_Object_Allocation
Allocate an object from the given FixedPool, initializing it with a specified value.
generic procedure Fixed_Object_Deallocation
Deallocate the memory at the given location.
generic function Flex_Object_Allocation
Allocate an object from the given FlexPool, initializing it with a specified value.
generic procedure Flex_Object_Deallocation
Deallocate the memory at the given location.
generic function Heap_Object_Allocation
Allocate an object from the given HeapPool, initializing it with a specified value.
procedure Initialize_Services
Initialize memory services.

Types

Table 10 lists the types in package V_Memory.

Table 10 Types
Name
Description
Fixed_Pool_ID
A private type used to identify FixedPools.
Flex_Pool_ID
A private types used to identify FlexPools.
Heap_Pool_ID
A private types used to identify HeapPools.

Exceptions

Table 11 lists the exceptions in package V_Memory.

Table 11 Exceptions
Name
Description
Bad_Block
A deallocation request is made of memory not identifiable as an allocated block from a pool.
Bad_Pool_Creation_Parameter
A pool cannot be created because a parameter passed to the create operation is unacceptable.
Invalid_Pool_ID
The pool ID passed to a pool operation does not correspond to an existing pool.
No_Available_Pool
A pool cannot be created because the maximum number of pools had already been allocated.
No_Memory
A memory request cannot be honored because of insufficient memory in the pool.
Object_Larger_Than_Fixed_Block_Size
An attempt is made to allocate from a FixedPool an object whose size is greater than the size of the blocks in the pool.
Unconstrained_Object
Raised by the allocation/deallocation subprograms if instantiated with an unconstrained object type.
Unexpected_V_Memory_Error
An unexpected error (an internal V_Memory bug) occurs during a V_Memory operation.

Package Specification


Procedures and Functions in Package V_Memory

procedure Create_Fixed_Pool

Syntax

Arguments

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

procedure Create_Flex_Pool

Syntax

Arguments

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

procedure Create_Heap_Pool

Syntax

Arguments

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

procedure Destroy_Fixed_Pool

Syntax

Arguments

Exceptions

procedure Destroy_Flex_Pool

Syntax

Arguments

Exceptions

procedure Destroy_Heap_Pool

Syntax

Arguments

Exceptions

generic function Fixed_Object_Allocation

Syntax

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

generic procedure Fixed_Object_Deallocation

Syntax

Arguments

Description

Fixed_Object_Deallocation deallocates memory at the given location.

Exceptions

generic function Flex_Object_Allocation

Syntax

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

generic procedure Flex_Object_Deallocation

Syntax

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

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

procedure Initialize_Services

Syntax

Arguments

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.
TOC PREV NEXT INDEX DOC LIST MASTER INDEX TECHNOTES APEX TIPS