casa
5.7.0-16
|
Memory related information and utilities. use visibility=export> More...
#include <Memory.h>
Static Public Member Functions | |
static size_t | allocatedMemoryInBytes () |
How much memory has been allocated by the programmer (via either new or malloc . More... | |
static size_t | assignedMemoryInBytes () |
How much memory in in the memory "pool" of this process. More... | |
static void | releaseMemory () |
Attempt to release memory which has been assigned but not allocated. More... | |
static void | setMemoryOptions () |
setMemoryOptions and setMemoryOption are typically front ends for mallopt which lets the user control some memory allocation parameters. More... | |
static int | setMemoryOption (int, int) |
Memory related information and utilities. use visibility=export>
This class should generally not be used by general application programmers. Instead you should use the memory information available in the AppInfo class.
This class reports on the dynamic ("heap") memory used by this process, and it can attempt to release some of that memory back to the operating system. The class reports on allocated
memory, which is memory that the process has actually requested, typically via new
, but also via malloc
. The number might be somewhat larger than actually requested by the programmer to account for overhead and alignment considerations. The class also reports assigned
memory, which is the total memory that the process has been given, not all of which has been allocated by the programmer. Typically this results from memory which has been delete
d by the programmer, but has not been released to the OS on the assumption that it might be needed again. (Getting and releasing memory to the OS can be expensive).
At present, the values for allocated and assigned memory are obtained via the mallinfo()
call, usually defined in malloc.h
. This call seems to be adequately portable for Unix. Another alternative would be to replace global operators new
and delete
for systems that do not have mallinfo()
.
The member function releaseMemory()
on some system will attempt to return assigned but unallocated memory to the OS. If the compilation system cannot automatically determine how to do this (at present it only recognizes Linux systems), you can you this function by setting the preprocessor symbol AIPS_RELEASEMEM
to a C++ statement which will release memory to the OS. For example, if you are using GNU malloc you could set it to malloc_trim(0)
. Note that releaseMemory()
might be a no-op on many systems, and that calling it might be expensive so it should not be called in tight-loops.
Note that this class does not use any Casacore facilities and does not cause any Casacore code to be linked in to your executable.
We could attempt to return memory to the OS when we are wasting a lot of memory as follows.
At run time we need to be able to make decisions about whether we should keep things in memory or about whether we should do I/O (e.g. use an Array or a PagedArray).
|
static |
How much memory has been allocated by the programmer (via either new
or malloc
.
This can include some extra overhead bytes, e.g. for alignment reasons.
|
static |
How much memory in in the memory "pool" of this process.
This includes not only the allocated memory, but some memory which has been delete
d but not returned to the OS on the assumption that it might be needed again.
|
static |
Attempt to release memory which has been assigned but not allocated.
On many systems this will be a no-op, and even on systems in which it does something the amount of reclaimed memory cannot be specified. Since this function may be somewhat expensive to call it should not be called too often.
|
static |
|
static |
setMemoryOptions and setMemoryOption are typically front ends for mallopt which lets the user control some memory allocation parameters.
setMemoryOptions is intended to be called only once at the start of a program while setMemoryOption could be called where desired (but see mallopt man page for possible side effects). Note: these two functions were added to address in a general way a memory fragmentation problem encountered on by the MIPSpro C++ compiler on the SGI.