Conference vaxaxp::alphanotes

   Use the RTL LIB$GET_VM services directly, or create your own memory
   manager layered on top of the C memory management routines. 

   In any event, I would strongly recommend centralizing all memory
   management calls into a single module, as this design will allow
   the easy implementation of memory management debugging in larger
   applications, when (not "if") this becomes necessary.  As part of
   this centralized design, you could choose to allocate fixed-size
   blocks of various sizes -- you could "round up" the allocated
   sizes, and force the C RTL (or your own explicit calls to the RTL
   LIB$ VM routines) to maintain a specific number of "lookaside lists".

   Various folks have posted similar suggestions in the DEC C conference,
   around centralizing the memory management, as well as schemes around
   adding an extra quadword at the front and at the back of the allocated
   storage, to allow the insertion of patterns that allow the detection
   of memory management corruptions.  (I've made several suggestions over
   there...)

   Direct use of the LIB$ VM routines allows one to designate the
   VM zone(s) used, and to designate the allocation sizes, and to
   implement the above debugging, and to access the memory statistics,
   and to implement "temporary memory" VM zones that can be quickly
   and entirely flushed via a single call.  There are other advantages.

   The C language has specific memory management behaviour expected, and
   this behaviour is fairly simple-minded -- among other behaviour, the
   last deallocation has traditionally tends to be cached pending a
   reallocation.  (There used to be the potential for a virtual memory
   leak because of this behaviour, but I believe this particular "leak"
   has been removed.)  

   The RTL folks will know if the LIB$ VM routines used by C have been
   extended to maintain seperate lookaside lists for the various sizes
   of allocations -- based on your comments, it would appear that the
   LIB$ VM routines or the C routines could benefit from the addition
   of a form of the "round up" scheme, should the routines find a large
   number of different size packets are required by the application.
  
   The OpenVMS version -- which is what the DEC C RTL shareable and
   the LIB shareable are both tied to -- would be of interest.

	--

   I'm curious as to why this question is here, I would have expected
   this in TURRIS::DECC (as it's a DEC C question), CLT::RTL (for the
   RTL VM routines "underneath" DEC C, or VAXAXP::VMSNOTES (for generic
   OpenVMS questions).  (VAXAXP::ALPHANOTES is the generic-Alpha and
   porting-to-Alpha conference.)

> Our problem is that we need to allocate, recursively, 
> many blocks of different sizes, which means that 
> thepointer returned grows until the page file quota is 
> over.

It would be helpful to see an example program that demonstrates
this problem.  The memory-allocation routines do remember the
block sizes you have used, but if you exceed your PAGFILQUO they
are supposed to coalesce the available free space to find a
block big enough for your allocation request.

What is your PAGFILQUO?  How much memory do you think is in use
when the program fails?  Does the application work on some other
platform?  (Are you sure it remembers to free every block it
allocates?)

Since you mention page file quota, I assume this is VMS.  And
since you posted your note here, I assume it's on Alpha.  What
version of OpenVMS Alpha are you using?

While Steve's suggestions in .1 have some merit,.you shouldn't
have to go to that trouble to make the application work.

     
    The LIBRTL routines behind the DEC C RTL routines
    do use a lookaside list for smaller allocations.
    
    Larger allocations are managed more as a heap.  There were
    a number of complaints of fragmentation of this heap and
    patches were issued for VAX and Alpha to make the merging
    of free'd memory more aggressive.
    
    If you have not installed any LIBRTL patches already, then
    you may want to see if this helps.
    
    (Note: if you installed the 10K patches this was included).
    
    _Paul