Michael Jones (mtj++at++babar)
Tue, 18 Jan 1994 09:53:30 -0800
:I need informations and precisions about memory allocation in Performer.
:
:What is the difference between :
: - pfMalloc(NULL)
pfMalloc(size, NULL) means call malloc(size)
: - pfMalloc(number, pfGetSharedArena())
: - arena = pfGetSharedArena(); pfMalloc(number, arena);
pfMalloc(size, arenaAddress) means allocate from the specified shared
memory arena. Using the pfGetSharedArena() function in the place of a
variable reference is simply an alternate C-language coding idiom.
Passing the value zero as the arenaAddress indicates that you want to use
the normal C-library malloc() function to allocate from non-shared heap
memory. If the arenaAddress argument is non-null, then it indicates the
address of a shared memory arena from which allocation should happen.
At startup, libpf establishes a shared memory arena for your (and it's) use.
The address of this arena is returned by pfGetShared Arena().
:What is the best way to allocate memory in Performer ?
malloc() if fine for unshared allocations.
pfMalloc(xxx, arenaAddress) is _mandatory_ for successful multiprocessing
if other processes must see the data you're allocating.
Since free() must be used for malloc()ed memory and pfFree() for pfMalloc()ed,
it seems safest to always use pfMalloc() and just pass a NULL arena pointer
when you don't need a shared address space allocation.
:When arena must be use in Performer ?
When the allocated data will be referenced by multiple processes, such as
the cull, draw, or intersection processes. The APP may instruct one of these
to do something at memory location 700000 (by passing a pointer) but in
the other process 700000 may have _NO RELATION WHATSOEVER_ to the APP's
data. If shared memory is used, though, you're assured that whatever data
pointer is returned by pfMalloc() will be at the same address in the other
processes.
:Is there a difference between the objects in Performer (pfMaterial, pfList,
: pfChannel, pfGroup, pfGeode ...) and the way you allocate
:them ?
All of the libpf objects--pfChannel, pfGroup, pfGeode--are automatically
allocated from the shared arena identified by pfGetSharedArena(). The libpr
objects--pfMaterial, pfFog, pfFrustum--are allocated in the address space
you specify in their pfNew() routine.
:When you are using Multi processing, what must be allocated in arena ?
Everything that will be referenced from more than one process.
Here's the reference page for pfMalloc. You'll find quite a lot of important
information in this page and in the IRIS Performer Programming Guide. Have
you looked at either of them yet?
pfMalloc(3pf) Silicon Graphics pfMalloc(3pf)
NAME
pfCalloc, pfRealloc, pfGetMallocArena, pfGetMallocSize, pfMalloc, pfFree
- Allocate, query, and free memory
C SPECIFICATION
#include <pr.h>
void* pfMalloc(size_t nbytes, void *arena);
void* pfCalloc(size_t numelem, size_t elsize, void *arena);
void* pfRealloc(void *ptr, size_t nbytes);
void* pfGetMallocArena(void *ptr);
long pfGetMallocSize(void *ptr);
void pfFree(void *ptr);
DESCRIPTION
These routines provide a general method to allocate memory, either from
the users heap (malloc) or from a shared memory arena (amalloc). In
addition, these routines provide a reference counting mechanism used by
IRIS Performer to efficiently manage memory.
pfMalloc operates identically to malloc(3C), except that a shared memory
arena may be specified to allocate the memory from. If arena is NULL,
memory is allocated from the heap, otherwise memory is allocated from
arena which must be a previously configured shared memory arena. Shared
memory arenas can be created using acreate.
pfCalloc and pfRealloc function just as their Unix counter- parts, except
that they may use shared arenas.
In all cases, a pointer to the allocated memory block is returned or NULL
if there is not enough available memory.
Memory allocated by pfMalloc/pfCalloc/pfRealloc has a special header
that, among other things, provides a reference count. Reference counts
are used to keep track of how many times a chunk of memory is referenced
or instanced. All IRIS Performer libpr objects (prObject) are created
with pfMalloc so their reference counts are updated by appropriate libpr
routines. Examples of references follow:
Example 1:
tex = pfNewTex(NULL);
/* Attach 'tex' to gstate0 and gstate1. */
pfGStateAttr(gstate0, PFSTATE_TEXTURE, tex);
pfGStateAttr(gstate1, PFSTATE_TEXTURE, tex);
/* The reference count of 'tex' is now 2. */
/* Remove 'tex' from gstate1. */
pfGStateAttr(gstate1, PFSTATE_TEXTURE, NULL);
/* The reference count of 'tex' is now 1. */
Example 2:
coords = (pfVec3*) pfMalloc(sizeof(pfVec3) * numVerts, arena);
/* Attach 'coords' to non-indexed pfGeoSet, 'gset'. */
pfGSetAttr(gset, PFGS_COORD3, PFGS_PER_VERTEX, coords, NULL);
/* The reference count of 'coords' is now 1. */
Example 3:
/* Attach 'gstate0' to 'gset' */
pfGSetGState(gset, gstate0);
/* The reference count of 'gstate0' is now incremented by 1. */
pfFree frees the memory associated with ptr. It is an error to pfFree
memory that was not allocated by pfMalloc/pfCalloc/pfRealloc and results
are undefined if any method other than pfFree or pfDelete (see below) is
used to free memory allocated by pfMalloc/pfCalloc/pfRealloc.
pfFree does not honor the reference count of ptr. This means that you can
free a chunk of memory that is still being used, i.e. - its reference
count is > 0, with potentially disastrous results in the form of mysteri-
ous memory trashing and segmentation violations.
pfDelete however, does honor the reference count of ptr and will not
delete any memory whose reference count is > 0. pfDelete returns -1 if
ptr is not a pfMalloc pointer, TRUE if ptr was deleted, and FALSE other-
wise. pfDelete is recommended if you are not sure of the reference count
of a piece of memory. See the pfObject man page for more details on
pfDelete.
pfGetMallocArena returns the arena pointer which ptr was allocated from
or NULL if ptr was allocated off the process heap.
pfGetMallocSize returns the size in bytes of the memory referenced by ptr
or -1 if ptr is not a pfMalloc pointer.
SEE ALSO
pfObject, acreate, malloc, calloc, realloc, free
--Be seeing you, mtj++at++sgi.com 415.390.1455 M/S 7L-590 Michael Jones Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:09 PDT