ear managers ,
Thanks to
"Darryl V. Pace" <dpace_at_tacticsus.com>
K.McManus_at_greenwich.ac.uk
Dr. Tom Blinn, 603-884-0646" <tpb_at_zk3.dec.com>
Lucio Chiappetti <lucio_at_ifctr.mi.cnr.it>
alan_at_nabeth.cxo.dec.com
for their answers.
Here is my question:
> Hi managers!
>
> I'm trying the way to have run-time allocation (and de-allocation) of memory
> in FORTRAN
> (AS 4100 Dunix 4.0b 512Mb 3CPU)
>
> I'm using the fortran malloc, falloc and free routines.
>
> My main program does the following
> loop:
> ask me for the number of byte I want to to alloc,
> then actually alloc (by malloc or falloc),
> then writes data to the obtained memory
> then frees the memory itself.
> end loop
>
> While running the above fortran program, I watched at the memory usage
> in my machine using ps and pvis.
>
> The memory parameters I traced are:
> virtual process size VSZ and resident process size RSS.
>
> It seems to me that the execution of the malloc increments the values of the sole VSZ
> while RSS grows up when the memory locations (provided by malloc) are actually written.
>
> The amazing (to me) thing is that none of the VSZ and RSS go back to lover values
> when the memory is freed (by free routine). The above values grow when a
> bigger region of memory is requested, but remain stable when is
> requested a smaller region.
>
> Can you help me in beeing sure that I actually free the no-more-usefull
> memory ?
>
> Thanks from Italy,
> Emanuele
here alan response:
Nearly all UNIX implementations of free(2) don't give
memory back to the operating system. The memory allocation
routines obtains memory for itself and then manages that
memory. Free returns it to the memory allocator. There
are routines on some systems that will return memory to
the system, but often they return all the memory past
a certain point. It isn't common that when memory is
freed, the allocation subsystem can give back some amount
of the memory, so few do.
Any reasonable demand paging system will find that the
free pages are not used and will page them out, making
the original physical page available for use elsewhere.
Other solutions available are to allocate large virtual
memory sections using mmap and a private paging file.
I don't know whether these routines are available from
FORTRAN, but a C interface to something that can use
them could probably be written.
here Tom response:
Take a look at the reference page for the sbrk() system call.
Think about how a high-level language implemention (like the C
libraries or Fortran)
might use sbrk() to allocate a memory region from which it can allocate
and free memory blocks for use by your program. Think about what's
required to "shrink" the allocated memory region and how likely it
would be to lead to program failures.
Then the observed behavior may make more sense to you.
Actually, the RSS would decrease if your application was no longer
actively
touching the memory and some other application was competing for
memory. As
long as there is enough physical memory in the system, a process'
pages are not pushed out to the swap/page area just for the sake of
generating disk traffic, and the RSS is only a measure of how many pages
are sitting in the
memory, not how many are actually being actively used.
You have to understand modern demand paged virtual memory systems for
any of this to make sense.
Here Darryl response:
With some OSes, when a process allocates memory, it leaves that
memory allocated even after the process stops just in case the process
is started again.
With the memory already allocated (after the first run of the process),
the OS does not have to go out to disk to get the process and bring it into
memory (which is a much slower process than just getting the process directly
from memory). This is process caching of a sort. From what you've
described, it sounds like Digital Unix is an OS that does this.
Lucio gave me some routines (f77 & c) to dynamically allocate memory.
Thank you lucio
but since I can use f90 i prefere to use ALLOCATABLE arrays.
--
Emanuele Lombardi
mail: AMB-GEM-CLIM ENEA Casaccia
I-00060 S.M. di Galeria (RM)
ITALY
mailto:lele_at_mantegna.casaccia.enea.it
tel +39 6 30483366
fax +39 6 30483591
Received on Fri Feb 20 1998 - 11:42:17 NZDT