Provided by: ion-doc_3.2.1+dfsg-1.1_all 
NAME
psm - Personal Space Management
SYNOPSIS
#include "psm.h"
typedef enum { Okay, Redundant, Refused } PsmMgtOutcome;
typedef unsigned long PsmAddress;
typedef struct psm_str
{
char *space;
int freeNeeded;
struct psm_str *trace;
int traceArea[3];
} PsmView, *PsmPartition;
[see description for available functions]
DESCRIPTION
PSM is a library of functions that support personal space management, that is, user management of an
application-configured memory partition. PSM is designed to be faster and more efficient than
malloc/free (for details, see the DETAILED DESCRIPTION below), but more importantly it provides a memory
management abstraction that insulates applications from differences in the management of private versus
shared memory.
PSM is often used to manage shared memory partitions. On most operating systems, separate tasks that
connect to a common shared memory partition are given the same base address with which to access the
partition. On some systems (such as Solaris) this is not necessarily the case; an absolute address
within such a shared partition will be mapped to different pointer values in different tasks. If a
pointer value is stored within shared memory and used without conversion by multiple tasks, segment
violations will occur.
PSM gets around this problem by providing functions for translating between local pointer values and
relative addresses within the shared memory partition. For complete portability, applications which
store addresses in shared memory should store these addresses as PSM relative addresses and convert them
to local pointer values before using them. The PsmAddress data type is provided for this purpose, along
with the conversion functions psa() and psp().
int psm_manage(char *start, unsigned int length, char *name, PsmPartition *partitionPointer,
PsmMgtOutcome *outcome)
Puts the length bytes of memory at start under PSM management, associating this memory partition with
the identifying string name (which is required and which can have a maximum string length of 31).
PSM can manage any contiguous range of addresses to which the application has access, typically a
block of heap memory returned by a malloc call.
Every other PSM API function must be passed a pointer to a local "partition" state structure
characterizing the PSM-managed memory to which the function is to be applied. The partition state
structure itself may be pre-allocated in static or local (or shared) memory by the application, in
which case a pointer to that structure must be passed to psm_manage() as the value of
*partitionPointer; if *partitionPointer is null, psm_manage() will use malloc() to allocate this
structure dynamically from local memory and will store a pointer to the structure in
*partitionPointer.
psm_manage() formats the managed memory as necessary and returns -1 on any error, 0 otherwise. The
outcome to the attempt to manage memory is placed in outcome. An outcome of Redundant means that the
memory at start is already under PSM management with the same name and size. An outcome of Refused
means that PSM was unable to put the memory at start under PSM management as directed; a diagnostic
message was posted to the message pool (see discussion of putErrmsg() in platform(3)).
char *psm_name(PsmPartition partition)
Returns the name associated with the partition at the time it was put under management.
char *psm_space(PsmPartition partition)
Returns the address of the space managed by PSM for partition. This function is provided to enable
the application to do an operating-system release (such as free()) of this memory when the managed
partition is no longer needed. NOTE that calling psm_erase() or psm_unmanage() [or any other PSM
function, for that matter] after releasing that space is virtually guaranteed to result in a
segmentation fault or other seriously bad behavior.
void *psp(PsmPartition partition, PsmAddress address)
address is an offset within the space managed for the partition. Returns the conversion of that
offset into a locally usable pointer.
PsmAddress psa(PsmPartition partition, void *pointer)
Returns the conversion of pointer into an offset within the space managed for the partition.
PsmAddress psm_malloc(PsmPartition partition, unsigned int length)
Allocates a block of memory from the "large pool" of the indicated partition. (See the DETAILED
DESCRIPTION below.) length is the size of the block to allocate; the maximum size is 1/2 of the
total address space (i.e., 2G for a 32-bit machine). Returns NULL if no free block could be found.
The block returned is aligned on a doubleword boundary.
void psm_panic(PsmPartition partition)
Forces the "large pool" memory allocation algorithm to hunt laboriously for free blocks in buckets
that may not contain any. This setting remains in force for the indicated partition until a
subsequent psm_relax() call reverses it.
void psm_relax(PsmPartition partition)
Reverses psm_panic(). Lets the "large pool" memory allocation algorithm return NULL when no free
block can be found easily.
PsmAddress psm_zalloc(PsmPartition partition, unsigned int length)
Allocates a block of memory from the "small pool" of the indicated partition, if possible; if the
requested block size -- length -- is too large for small pool allocation (which is limited to 64
words, i.e., 256 bytes for a 32-bit machine), or if no small pool space is available and the size of
the small pool cannot be increased, then allocates from the large pool instead. Small pool
allocation is performed by an especially speedy algorithm, and minimum space is consumed in memory
management overhead for small-pool blocks. Returns NULL if no free block could be found. The block
returned is aligned on a word boundary.
void psm_free(PsmPartition partition, PsmAddress block)
Frees for subsequent re-allocation the indicated block of memory from the indicated partition. block
may have been allocated by either psm_malloc() or psm_zalloc().
int psm_set_root(PsmPartition partition, PsmAddress root)
Sets the "root" word of the indicated partition (a word at a fixed, private location in the PSM
bookkeeping data area) to the indicated value. This function is typically useful in a shared-memory
environment, such as a VxWorks address space, in which a task wants to retrieve from the indicated
partition some data that was inserted into the partition by some other task; the partition root word
enables multiple tasks to navigate the same data in the same PSM partition in shared memory. The
argument is normally a pointer to something like a linked list of the linked lists that populate the
partition; in particular, it is likely to be an object catalog (see psm_add_catlg()). Returns 0 on
success, -1 on any failure (e.g., the partition already has a root object, in which case
psm_erase_root() must be called before psm_set_root()).
PsmAddress psm_get_root(PsmPartition partition)
Retrieves the current value of the root word of the indicated partition.
void psm_erase_root(PsmPartition partition)
Erases the current value of the root word of the indicated partition.
PsmAddress psm_add_catlg(PsmPartition partition)
Allocates space for an object catalog in the indicated partition and establishes the new catalog as
the partition's root object. Returns 0 on success, -1 on any error (e.g., the partition already has
some other root object).
int psm_catlg(PsmPartition partition, char *objName, PsmAddress objLocation)
Inserts an entry for the indicated object into the catalog that is the root object for this
partition. The length of objName cannot exceed 32 bytes, and objName must be unique in the catalog.
Returns 0 on success, -1 on any error.
int psm_uncatlg(PsmPartition partition, char *objName)
Removes the entry for the named object from the catalog that is the root object for this partition,
if that object is found in the catalog. Returns 0 on success, -1 on any error.
int psm_locate(PsmPartition partition, char *objName, PsmAddress *objLocation, PsmAddress *entryElt)
Places in *objLocation the address associated with objName in the catalog that is the root object for
this partition and places in *entryElt the address of the list element that points to this catalog
entry. If name is not found in catalog, set *entryElt to zero. Returns 0 on success, -1 on any
error.
void psm_usage(PsmPartition partition, PsmUsageSummary *summary)
Loads the indicated PsmUsageSummary structure with a snapshot of the indicated partition's usage
status. PsmUsageSummary is defined by:
typedef struct {
char partitionName[32];
unsigned int partitionSize;
unsigned int smallPoolSize;
unsigned int smallPoolFreeBlockCount[SMALL_SIZES];
unsigned int smallPoolFree;
unsigned int smallPoolAllocated;
unsigned int largePoolSize;
unsigned int largePoolFreeBlockCount[LARGE_ORDERS];
unsigned int largePoolFree;
unsigned int largePoolAllocated;
unsigned int unusedSize;
} PsmUsageSummary;
void psm_report(PsmUsageSummary *summary)
Sends to stdout the content of summary, a snapshot of a partition's usage status.
void psm_unmanage(PsmPartition partition)
Terminates local PSM management of the memory in partition and destroys the partition state structure
*partition, but doesn't erase anything in the managed memory; PSM management can be re-established by
a subsequent call to psm_manage().
void psm_erase(PsmPartition partition)
Unmanages the indicated partition and additionally discards all information in the managed memory,
preventing re-management of the partition.
MEMORY USAGE TRACING
If PSM_TRACE is defined at the time the PSM source code is compiled, the system includes built-in support
for simple tracing of memory usage: memory allocations are logged, and memory deallocations are matched
to logged allocations, "closing" them. This enables memory leaks and some other kinds of memory access
problems to be readily investigated.
int psm_start_trace(PsmPartition partition, int traceLogSize, char *traceLogAddress)
Begins an episode of PSM memory usage tracing. traceLogSize is the number of bytes of shared memory
to use for trace activity logging; the frequency with which "closed" trace log events must be deleted
will vary inversely with the amount of memory allocated for the trace log. traceLogAddress is
normally NULL, causing the trace system to allocate traceLogSize bytes of shared memory dynamically
for trace logging; if non-NULL, it must point to traceLogSize bytes of shared memory that have been
pre-allocated by the application for this purpose. Returns 0 on success, -1 on any failure.
void psm_print_trace(PsmPartition partition, int verbose)
Prints a cumulative trace report and current usage report for partition. If verbose is zero, only
exceptions (notably, trace log events that remain open -- potential memory leaks) are printed;
otherwise all activity in the trace log is printed.
void psm_clear_trace(PsmPartition partition)
Deletes all closed trace log events from the log, freeing up memory for additional tracing.
void psm_stop_trace(PsmPartition partition)
Ends the current episode of PSM memory usage tracing. If the shared memory used for the trace log
was allocated by psm_start_trace(), releases that shared memory.
EXAMPLE
For an example of the use of psm, see the file psmshell.c in the PSM source directory.
USER'S GUIDE
Compiling a PSM application
Just be sure to "#include "psm.h"" at the top of each source file that includes any PSM function
calls.
Linking/loading a PSM application
a. In a UNIX environment, link with libpsm.a.
b. In a VxWorks environment, use
ld 1, 0, "libpsm.o"
to load PSM on the target before loading any PSM applications.
Typical usage:
a. Call psm_manage() to initiate management of the partition.
b. Call psm_malloc() (and/or psm_zalloc()) to allocate space in the partition; call psm_free() to
release space for later re-allocation.
c. When psm_malloc() returns NULL and you're willing to wait a while for a more exhaustive free block
search, call psm_panic() before retrying psm_malloc(). When you're no longer so desperate for space,
call psm_relax().
d. To store a vital pointer in the single predefined location in the partition that PSM reserves for
this purpose, call psm_set_root(); to retrieve that pointer, call psm_get_root().
e. To get a snapshot of the current configuration of the partition, call psm_usage(). To print this
snapshot to stdout, call psm_report().
f. When you're done with the partition but want to leave it in its current state for future re-
management (e.g., if the partition is in shared memory), call psm_unmanage(). If you're done with
the partition forever, call psm_erase().
DETAILED DESCRIPTION
PSM supports user management of an application-configured memory partition. The partition is functionally
divided into two pools of variable size: a "small pool" of low-overhead blocks aligned on 4-byte
boundaries that can each contain up to 256 bytes of user data, and a "large pool" of high-overhead blocks
aligned on 8-byte boundaries that can each contain up to 2GB of user data.
Space in the small pool is allocated in any one of 64 different block sizes; each possible block size is
(4i + n) where i is a "block list index" from 1 through 64 and n is the length of the PSM overhead
information per block [4 bytes on a 32-bit machine]. Given a user request for a block of size q where q
is in the range 1 through 256 inclusive, we return the first block on the j'th small-pool free list where
j = (q - 1) / 4. If there is no such block, we increase the size of the small pool [incrementing its
upper limit by (4 * (j + 1)) + n], initialize the increase as a free block from list j, and return that
block. No attempt is made to consolidate physically adjacent blocks when they are freed or to bisect
large blocks to satisfy requests for small ones; if there is no free block of the requested size and the
size of the small pool cannot be increased without encroaching on the large pool (or if the requested
size exceeds 256), we attempt to allocate a large-pool block as described below. The differences between
small-pool and large-pool blocks are transparent to the user, and small-pool and large-pool blocks can be
freely intermixed in an application.
Small-pool blocks are allocated and freed very rapidly, and space overhead consumption is small, but
capacity per block is limited and space assigned to small-pool blocks of a given size is never again
available for any other purpose. The small pool is designed to satisfy requests for allocation of a
stable overall population of small, volatile objects such as List and ListElt structures (see lyst(3)).
Space in the large pool is allocated from any one of 29 buckets, one for each power of 2 in the range 8
through 2G. The size of each block can be expressed as (n + 8i + m) where i is any integer in the range
1 through 256M, n is the size of the block's leading overhead area [8 bytes on a 32-bit machine], and m
is the size of the block's trailing overhead area [also 8 bytes on a 32-bit machine]. Given a user
request for a block of size q where q is in the range 1 through 2G inclusive, we first compute r as the
smallest multiple of 8 that is greater than or equal to q. We then allocate the first block in bucket t
such that 2 ** (t + 3) is the smallest power of 2 that is greater than r [or, if r is a power of 2, the
first block in bucket t such that 2 ** (t + 3) = r]. That is, we try to allocate blocks of size 8 from
bucket 0 [2**3 = 8], blocks of size 16 from bucket 1 [2**4 = 16], blocks of size 24 from bucket 2 [2**5 =
32, 32 > 24], blocks of size 32 from bucket 2 [2**5 = 32], and so on. t is the first bucket whose free
blocks are ALL guaranteed to be at least as large as r; bucket t - 1 may also contain some blocks that
are as large as r (e.g., bucket 1 will contain blocks of size 24 as well as blocks of size 16), but we
would have to do a possibly time consuming sequential search through the free blocks in that bucket to
find a match, because free blocks within a bucket are stored in no particular order.
If bucket t is empty, we allocate the first block from the first non-empty bucket corresponding to a
greater power of two; if all eligible bucket are empty, we increase the size of the large pool
[decrementing its lower limit by (r + 16)], initialize the increase as a free block and "free" it, and
try again. If the size of the large pool cannot be increased without encroaching on the small pool, then
if we are desperate we search sequentially through all blocks in bucket t - 1 (some of which may be of
size r or greater) and allocate the first block that is big enough, if any. Otherwise, no block is
returned.
Having selected a free block to allocate, we remove the allocated block from the free list, split off as
a new free block all bytes in excess of (r + 16) bytes [unless that excess is too small to form a legal-
size block], and return the remainder to the user. When a block is freed, it is automatically
consolidated with the physically preceding block (if that block is free) and the physically subsequent
block (if that block is free).
Large-pool blocks are allocated and freed quite rapidly; capacity is effectively unlimited; space
overhead consumption is very high for extremely small objects but becomes an insignificant fraction of
block size as block size increases. The large pool is designed to serve as a general-purpose heap with
minimal fragmentation whose overhead is best justified when used to store relatively large, long-lived
objects such as image packets.
The general goal of this memory allocation scheme is to satisfy memory management requests rapidly and
yet minimize the chance of refusing a memory allocation request when adequate unused space exists but is
inaccessible (because it is fragmentary or is buried as unused space in a block that is larger than
necessary). The size of a small-pool block delivered to satisfy a request for q bytes will never exceed
q + 3 (alignment), plus 4 bytes of overhead. The size of a large-pool block delivered to satisfy a
request for q bytes will never exceed q + 7 (alignment) + 20 (the maximum excess that can't be split off
as a separate free block), plus 16 bytes of overhead.
Neither the small pool nor the large pool ever decrease in size, but large-pool space previously
allocated and freed is available for small-pool allocation requests if no small-pool space is available.
Small-pool space previously allocated and freed cannot easily be reassigned to the large pool, though,
because blocks in the large pool must be physically contiguous to support defragmentation. No such
reassignment algorithm has yet been developed.
SEE ALSO
lyst(3)