The Question is:
How does Dec C's calloc and malloc functions operate with VAX memory paging
If WORKING SET is on it's WORK EXTEND limit does it make more room by
swapping when you are asking more memory by calloc or malloc functions ? My
experience is that it does not but returns NULL pointer because it could not
allocate any free memory.
How it have to be done that system could handle allocation right way,
swapping out process unused pages and making free memory for allocation ?
The Answer is :
The C calloc, malloc, and free calls use LIB RTL services for memory
requests, and can interoperate with other RTL memory management calls.
(While the pool of memory available to the image can be shared and
C and RTL memory calls can all operate in parallel, the various calls
should not be intermixed on the same allocated memory areas. Use the
C free call for memory allocated via malloc or calloc, and use the
lib$free_vm for memory allocated via lib$get_vm)
If OpenVMS can acquire sufficient free physical memory and if the
process quotas and system parameters permit it, the virtual memory
allocation request will be honored.
If the process is at its working set quota and no other free physical
memory is available is available to extend the working set, or if the
process is at its working set extent, then memory will have to be
faulted out of the process before memory can be faulted in.
A lack of free physical memory or sufficient free space in the system
backing storage (eg: pagefile) generally results in application and
system performance reductions (potentially severe, of course), while
a lack of process pagefile quota or free virtual address space will
result in memory allocation failures.
If OpenVMS cannot honor the request to allocate memory, then an error
will be returned. Direct use of the RTL calls provides a rather better
interface, as the C calls are necessarily generic in nature and as the
RTL calls provide more specific error messages and can also provide
additional memory-related capabilities.