Re: Idl is greedy, once it gets some memory it will NOT release it. [message #5515] |
Tue, 16 January 1996 00:00 |
korpela
Messages: 59 Registered: September 1993
|
Member |
|
|
In article <4de71m$et5@netline-fddi.jpl.nasa.gov>,
Ramanujam Raghunath <rxr@pacific.jpl.nasa.gov> wrote:
> Hello all:
> I have a question on IDL's memory management. My problem could also be in the
> swap space management in the SUNOS and IRIX 5.3, but I doubt it.
> The issue is, after an array is deleted in IDL, the memory it occupied does not
> seem to be released (is the impression you get when you make an enquiry on the
> swap space from the O/S (swap -s in IRIX)) until the IDL session is exited;
> but seems to have been when you make an enquiry on the memory in IDL, using
> help, /memory.
This is a result of IDL being written in C and using the C library functions
(malloc and free) for memory allocation. In most C libraries, memory that is
freed is NOT returned to the operating system. The C program retains this
memory and will reuse it for future calls to malloc (assuming that the new
allocation will fit in the freed block).
Another way of considering it is in terms of how memory allocation is done
under UNIX. New memory is allocated using brk() or sbrk() which control
the size of the data segment. These routines are called by malloc().
Suppose you allocate 3 1 MB regions of memory under C.
char *p1=(char *)malloc(3*1024*1024);
char *p2=(char *)malloc(3*1024*1024);
char *p3=(char *)malloc(3*1024*1024);
Here's what your data segment would look like assuming malloc had to call
sbrk().
------------------------------------------------------------ ---
prev stuff | overhead | 3MB | overhead | 3MB | overhead | 3MB |
------------------------------------------------------------ ---
^ ^ ^ ^
p1 p2 p3 end of segment.
Now we free(p1).
------------------------------------------------------------ ----
prev stuff | overhead | free | overhead | 3MB | overhead | 3MB |
------------------------------------------------------------ ----
^ ^ ^
p2 p3 end of segment
Notice that the free memory is still in the data segment. If free
had called brk to reduce the size of the segment, the 3MB pointed to
my p3 would be outside the data segment! SIGSEGV city! If free had
moved the allocated memory to lower addresses so the segment size
could be reduced without losing data, then p2 and p3 would point to
invalid addresses, and we'd be forced to use handles rather than pointers
and call GetPointerFromHandle() every time we wanted to access the memory.
Ick! Just like Windows!
Eric
--
Eric Korpela | An object at rest can never be
korpela@ssl.berkeley.edu | stopped.
<a href=" http://www.cs.indiana.edu/finger/mofo.ssl.berkeley.edu/korpe la/w">
Click here for more info.</a>
|
|
|
Re: Idl is greedy, once it gets some memory it will NOT release it. [message #5519 is a reply to message #5515] |
Tue, 16 January 1996 00:00  |
peter
Messages: 80 Registered: February 1994
|
Member |
|
|
Ramanujam Raghunath (rxr@pacific.jpl.nasa.gov) wrote:
: Hello all:
: I have a question on IDL's memory management. My problem could also be in the
: swap space management in the SUNOS and IRIX 5.3, but I doubt it.
: The issue is, after an array is deleted in IDL, the memory it occupied does not
: seem to be released (is the impression you get when you make an enquiry on the
: swap space from the O/S (swap -s in IRIX)) until the IDL session is exited;
: but seems to have been when you make an enquiry on the memory in IDL, using
: help, /memory.
True. Also true for any other unix program, as far as I know, since
memory cannot be released back to the operating system. On the other
hand, the next time IDL needs more memory, it won't get yet another
chunk from the system, but will re-use what has been free'd (with
caveats for fragmentation, etc).
Peter
|
|
|
Re: Idl is greedy, once it gets some memory it will NOT release it. [message #5521 is a reply to message #5515] |
Tue, 16 January 1996 00:00  |
kak
Messages: 16 Registered: February 1995
|
Junior Member |
|
|
rxr@pacific.jpl.nasa.gov (Ramanujam Raghunath) writes:
> Hello all:
> I have a question on IDL's memory management. My problem could also be in the
> swap space management in the SUNOS and IRIX 5.3, but I doubt it.
> The issue is, after an array is deleted in IDL, the memory it occupied does not
> seem to be released (is the impression you get when you make an enquiry on the
> swap space from the O/S (swap -s in IRIX)) until the IDL session is exited;
> but seems to have been when you make an enquiry on the memory in IDL, using
> help, /memory.
<example session deleted>
Well, I think this feature/bug has been in IDL for UNIX workstations
from the beginning as far as I can remember. In a thread a while ago,
some people claimed that the internal IDL routines for garbage collection
and memory deallocation are flawed.
I once stumbled over a comment from RSI where they said that
this has to do with a principal uncompatibility of the respective UNIX
runtime library routines with their internal memory organization.
Can someone shed more light on this?
On the other hand, I checked this on IDL for Windows 3.1 and it seemed
to work there...
Cheers,
Karl
--
IPP, PO Box 1533 | Phone: +49-89-3299-1655 | E-Mail:
D-85740 Garching | FAX : +49-89-3299-1149 | kak@ipp-garching.mpg.de
PGP key available: finger -l kak@uts.ipp-garching.mpg.de
|
|
|
Re: Idl is greedy, once it gets some memory it will NOT release it. [message #5525 is a reply to message #5515] |
Tue, 16 January 1996 00:00  |
kspencer
Messages: 21 Registered: December 1993
|
Junior Member |
|
|
rxr@pacific.jpl.nasa.gov (Ramanujam Raghunath) writes:
> Hello all:
> I have a question on IDL's memory management. My problem could also be in the
> swap space management in the SUNOS and IRIX 5.3, but I doubt it.
> The issue is, after an array is deleted in IDL, the memory it occupied does not
> seem to be released (is the impression you get when you make an enquiry on the
> swap space from the O/S (swap -s in IRIX)) until the IDL session is exited;
> but seems to have been when you make an enquiry on the memory in IDL, using
> help, /memory.
You are kindly directed to the FAQ.
-----------------------------------------------------------
Kevin Spencer
Cognitive Psychophysiology Laboratory and Beckman Institute
University of Illinois at Urbana-Champaign
kspencer@p300.cpl.uiuc.edu / kspencer@psych.uiuc.edu
-----------------------------------------------------------
|
|
|