I'm supporting a giant legacy app that allocates memory in lots of 
places.  It sure would be handy to have a "deallocate all" function. 
Does any version of fortran have such a thing?

On Jul 14, 9:07 pm, A Watcher <stocks...@earthlink.net> wrote:
> I'm supporting a giant legacy app that allocates memory in lots of
> places.  It sure would be handy to have a "deallocate all" function.
> Does any version of fortran have such a thing?

I cannot tell exactly what you want.  Does the legacy app
use standard Fortran pointers or LWG/Cray/DEC/Sun pointers
(which are nonstandard)?  If it uses standard Fortran
pointers, do you expect pointers that pointed to targets
that were deallocated to be nullified?  Would an
implementation that does garbage collection suffice for
your purposes?

Robert Corbett

A Watcher wrote in message ...
>I'm supporting a giant legacy app that allocates memory in lots of
>places.  It sure would be handy to have a "deallocate all" function.
>Does any version of fortran have such a thing?

Yes; execute a STOP instruction.

A Watcher wrote:
> I'm supporting a giant legacy app that allocates memory in lots of
> places.  It sure would be handy to have a "deallocate all" function.
> Does any version of fortran have such a thing?


I'd imagine that, if the app is indeed big enough and the project budget 
permits it, it would be possible to write a script that generates such a 
deallocation routine.

That script would only need to parse the entire code, collect all 
pointer-based variables and allocatable arrays, put them in a COMMON 
block or MODULE if neccessary (so they are globally accessible) and then 
generate a large DEALLOCATE statement.

If you're savvy enough, such a script could probably be written in 
Python or the likes in a single day.


However, as others have pointed out, everything gets deallocated on exit 
anyway, so you should seriously think about whether that is really 
neccessary.

-- 
-- Philipp Emanuel Weidmann

On 15 jul, 14:12, "Philipp E. Weidmann" <philipp.weidm...@gmx.de>
wrote:
> A Watcher wrote:
> > I'm supporting a giant legacy app that allocates memory in lots of
> > places. =A0It sure would be handy to have a "deallocate all" function.
> > Does any version of fortran have such a thing?
>
> I'd imagine that, if the app is indeed big enough and the project budget
> permits it, it would be possible to write a script that generates such a
> deallocation routine.
>
> That script would only need to parse the entire code, collect all
> pointer-based variables and allocatable arrays, put them in a COMMON
> block or MODULE if neccessary (so they are globally accessible) and then
> generate a large DEALLOCATE statement.
>
> If you're savvy enough, such a script could probably be written in
> Python or the likes in a single day.
>
> However, as others have pointed out, everything gets deallocated on exit
> anyway, so you should seriously think about whether that is really
> neccessary.
>
> --
> -- Philipp Emanuel Weidmann

If the allocation is done for ALLOCATABLE items and not for POINTER
items,
then garbage collection is automatic too.

Perhaps "A Watcher" should explain what the symptoms are of the
program
that prompted this question, because such gross memory management as
asked about seems unlikely to be useful, except, indeed at the end
of the program, but then the OS should take care of it.

Regards,

Arjen

On 2010-07-15 10:18:41 -0300, Arjen Markus <arjen.markus895@gmail.com> said:

> On 15 jul, 14:12, "Philipp E. Weidmann" <philipp.weidm...@gmx.de>
> wrote:
>> A Watcher wrote:
>>> I'm supporting a giant legacy app that allocates memory in lots of
>>> places. �It sure would be handy to have a "deallocate all" function.
>>> Does any version of fortran have such a thing?
>> 
>> I'd imagine that, if the app is indeed big enough and the project budget
>> permits it, it would be possible to write a script that generates such a
>> deallocation routine.
>> 
>> That script would only need to parse the entire code, collect all
>> pointer-based variables and allocatable arrays, put them in a COMMON
>> block or MODULE if neccessary (so they are globally accessible) and then
>> generate a large DEALLOCATE statement.
>> 
>> If you're savvy enough, such a script could probably be written in
>> Python or the likes in a single day.
>> 
>> However, as others have pointed out, everything gets deallocated on exit
>> anyway, so you should seriously think about whether that is really
>> neccessary.
>> 
>> --
>> -- Philipp Emanuel Weidmann
> 
> If the allocation is done for ALLOCATABLE items and not for POINTER
> items,
> then garbage collection is automatic too.
> 
> Perhaps "A Watcher" should explain what the symptoms are of the
> program
> that prompted this question, because such gross memory management as
> asked about seems unlikely to be useful, except, indeed at the end
> of the program, but then the OS should take care of it.
> 
> Regards,
> 
> Arjen

A common problem is turning a main program which executed once into a
subroutine that can be executed several times. The ALLOCATE of an
ALLOCATABLE will fail on the second execution. The memory leak for
pointers may cause other failures after repeated executions of the
new subroutine.

An intermediate solution is to repeatedly execute the main from a script
but that may not make sense for all sorts of good reasons.

A function that gives the total memory allocated would be very useful.
(Hint for compiler vendors!!) It would allow one to monitor the success
of the deallocations as wellas the presence of memory leaks. Garbage
collection is nice but not always present and it has its own drawbacks.

In article <2010071510314516807-GordonSande@gmailcom>,
 Gordon Sande <Gordon.Sande@gmail.com> wrote:

> A function that gives the total memory allocated would be very useful.
> (Hint for compiler vendors!!)

Yes, this cannot be overstated.  I know many legacy codes that avoid 
fortran allocate/deallocate and automatic arrays for this very reason, 
preferring instead to use their legacy approach.  Particularly on 
parallel computers which have (relatively) limited memory, it is 
critical to monitor the memory usage.  Sometimes, programs even choose 
which branches to take (and which algorithms to use) based on runtime 
memory usage.  Sometimes you must submit your job to a different queue 
depending on its memory usage, and if it overruns (say, because of some 
automatic array somewhere) your job will abort.

$.02 -Ron Shepard

Ron Shepard <ron-shepard@nospam.comcast.net> wrote:
> In article <2010071510314516807-GordonSande@gmailcom>,
> Gordon Sande <Gordon.Sande@gmail.com> wrote:
 
>> A function that gives the total memory allocated would be very useful.
>> (Hint for compiler vendors!!)
 
> Yes, this cannot be overstated.  I know many legacy codes that avoid 
> fortran allocate/deallocate and automatic arrays for this very reason, 
> preferring instead to use their legacy approach.  

There are other Fortran features that you also can't use.  Array
operations can require temporary arrays.  A PL/I compiler I used
many years ago gave a warning when a temporary array was to be used,
such that one might modify the code.  I don't know if any Fortran
compilers do that.  (That was when memories were smaller, though.

> Particularly on 
> parallel computers which have (relatively) limited memory, it is 
> critical to monitor the memory usage.  Sometimes, programs even choose 
> which branches to take (and which algorithms to use) based on runtime 
> memory usage.  Sometimes you must submit your job to a different queue 
> depending on its memory usage, and if it overruns (say, because of some 
> automatic array somewhere) your job will abort.

It would also be nice to know how much memory is available, but 
many systems don't have a good way to tell you that.  On many, it
can change as other programs allocate and free memory, making it
even harder.  (As soon as you find out how much is available, 
some other task might use some of it.)  In most cases, the ability
to detect allocation failure and retry with a different size is
about as good as you can do.

-- glen

On 18 juil, 02:06, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Ron Shepard <ron-shep...@nospam.comcast.net> wrote:
> > In article <2010071510314516807-GordonSande@gmailcom>,
> > Gordon Sande <Gordon.Sa...@gmail.com> wrote:
> >> A function that gives the total memory allocated would be very useful.
> >> (Hint for compiler vendors!!)
> > Yes, this cannot be overstated. =A0I know many legacy codes that avoid
> > fortran allocate/deallocate and automatic arrays for this very reason,
> > preferring instead to use their legacy approach. =A0
>
> There are other Fortran features that you also can't use. =A0Array
> operations can require temporary arrays. =A0A PL/I compiler I used
> many years ago gave a warning when a temporary array was to be used,
> such that one might modify the code. =A0I don't know if any Fortran
> compilers do that. =A0(That was when memories were smaller, though.

The intel compiler, with the right compiling option, issues such
warning when allocating a temporary array to pass it by argument to a
subroutine or function.

But the warning is there to indicate a possible performance loss.
>
> > Particularly on
> > parallel computers which have (relatively) limited memory, it is
> > critical to monitor the memory usage. =A0Sometimes, programs even choos=
e
> > which branches to take (and which algorithms to use) based on runtime
> > memory usage. =A0Sometimes you must submit your job to a different queu=
e
> > depending on its memory usage, and if it overruns (say, because of some
> > automatic array somewhere) your job will abort.
>
> It would also be nice to know how much memory is available, but
> many systems don't have a good way to tell you that. =A0On many, it
> can change as other programs allocate and free memory, making it
> even harder. =A0(As soon as you find out how much is available,
> some other task might use some of it.) =A0In most cases, the ability
> to detect allocation failure and retry with a different size is
> about as good as you can do.
>
> -- glen

I am in need of a similar feature. As Gordon mentioned, I have converted an old (but maintained) Fortran simulation model into a subroutine within an optimization. There are lots of pointers that get allocated but never deallocated. My program leaks an additional 40MB of RAM with each call to the simulation so I just want to be able to clear all memory usage at the end of the routine. Should I just have a series of: If(ALLOCATED(pointer_array)DEALLOCATE(pointer_array) ?

spmcgee wrote:
> I am in need of a similar feature. As Gordon mentioned, I have converted an old (but maintained) Fortran simulation model into a subroutine within an optimization. There are lots of pointers that get allocated but never deallocated. My program leaks an additional 40MB of RAM with each call to the simulation so I just want to be able to clear all memory usage at the end of the routine. Should I just have a series of: If(ALLOCATED(pointer_array)DEALLOCATE(pointer_array) ?

yes that should work.  however, for pointers, that should be:
IF(ASSOCIATED(pointer_array)DEALLOCATE(pointer_array)

spmcgee <cerpintaxt03@gmail.com> wrote:

> I am in need of a similar feature. As Gordon mentioned, 
> I have converted an old (but maintained) Fortran simulation 
> model into a subroutine within an optimization. 
> There are lots of pointers that get allocated but never 
> deallocated. My program leaks an additional 40MB of RAM with 
> each call to the simulation so I just want to be able 
> to clear all memory usage at the end of the routine. 
> Should I just have a series of: 
> If(ALLOCATED(pointer_array)DEALLOCATE(pointer_array) ?

As long as none of the allocated memory contains pointers,
such as inside structures, that should be fine.

If it does, often in linked-lists or trees, then you have to be
sure to dealloate the pointers inside before deallocating the
array itself.

-- glen

Tom Micevski <none@au-e29b6ec0.invalid> wrote:

> spmcgee wrote:
> > I am in need of a similar feature. As Gordon mentioned, I have converted
> > an old (but maintained) Fortran simulation model into a subroutine
> > within an optimization. There are lots of pointers that get allocated
> > but never deallocated. My program leaks an additional 40MB of RAM with
> > each call to the simulation so I just want to be able to clear all
> > memory usage at the end of the routine. Should I just have a series of:
> > If(ALLOCATED(pointer_array)DEALLOCATE(pointer_array) ?
> 
> yes that should work.  however, for pointers, that should be:
> IF(ASSOCIATED(pointer_array)DEALLOCATE(pointer_array)

Also, watch out for pointers with undefined association status. That
problem comes up a lot. It is only valid to use the ASSOCIATED intrinsic
if you independently know that the pointer association status is
defined. The ASSOCIATED intrinsic can distinguish associated from
disassociated (aka nullified). But it cannot handle the possibility of
undefined association status. That caveat needs to be mentioned almost
any time that the ASSOCIATED intrinsic comes up. In fact, it isn't
unusual for the associated intrinsic to be redundant in that by the time
you have made certain that the pointer is not undefined, you might also
have figured out whether it is associated or null.

I might also put in a plug for allocatables instead of pointers. It
depends on the particular usage, but quite often pointers were used as a
substitute for allocatables because of the severe limitations on
allocatables in f90 (and f95 without the allocatable TR). Allocatables
inherently have fewer problems with memory leaks. And they don't have
issues like undefined status; the status of an allocatable is always
defined as of f95. (F90 was a different story, but you are unlikely to
have to deal with the horrible state of allocatables in f90). Of course,
since you have existing code, conversion to allocatables would certainly
add extra work, but it is at least concievable that the work might pay
off in reduced maintenance costs.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

In article <1kq0n8a.6e22241107lzgN%nospam@see.signature>,
 nospam@see.signature (Richard Maine) wrote:

> I might also put in a plug for allocatables instead of pointers. It
> depends on the particular usage, but quite often pointers were used as a
> substitute for allocatables because of the severe limitations on
> allocatables in f90 (and f95 without the allocatable TR). Allocatables
> inherently have fewer problems with memory leaks. And they don't have
> issues like undefined status; the status of an allocatable is always
> defined as of f95. (F90 was a different story, but you are unlikely to
> have to deal with the horrible state of allocatables in f90). Of course,
> since you have existing code, conversion to allocatables would certainly
> add extra work, but it is at least concievable that the work might pay
> off in reduced maintenance costs.

There are two useful features of allocatables in this respect. One 
is that locally defined allocatables within a subroutine are 
automatically deallocated upon exit.  That means that you do not 
need to deallocate them explicitly yourself, which is important, for 
example, when the subroutine has multiple return statements.  The 
other nice feature is when you have nested user defined types that 
contains allocatable components at various levels.  Instead of 
starting at the bottom and deallocating everything yourself as you 
go up level by level, a single deallocate() statement for the top 
level structure is sufficient.  The compiler itself knows how to 
track everything from bottom to top appropriately.

$.02 -Ron Shepard

Thanks for the replies.

I fixed the leaks with just a single DEALLOCATE(pointer_arrays) statement and just included all the pointer arrays that I know to be allocated. I don't understand why pointers are needed at all and I'd love to change them to allocatables but the code is just to involved and I can't go there. 

There is a user defined type that has all the same pointer arrays in it which are associated with module pointer arrays of the same name. For example

    MODULE VDFMODULE
        INTEGER, SAVE, POINTER :: A
      TYPE VDFTYPE
        INTEGER, POINTER :: A
      END TYPE
      TYPE(VDFTYPE),SAVE:: VDFDAT(10)
    END MODULE VDFMODULE

A is then allocated in a subroutine but never deallocated (this was the source of the leak). However, there is another subroutine later with statements like:

      SUBROUTINE SVDF
      USE VDFMODULE
      VDFDAT(1)%A=>A
      RETURN
      END

Q1 - What is the purpose of pointing a pointer within VDFDAT to a pointer of the same name. Why would a programmer want to do such shenanigans?

Q2 - Do I need to deallocate all the pointers in VDFDAT as well as the stand alone pointers?

Q3 - I don't really understand the following precaution from glen
"As long as none of the allocated memory contains pointers"
How can I check for this and what exactly would I be checking for?

> Q1 - What is the purpose of pointing a pointer within VDFDAT to a  =

> pointer of the same name. Why would a programmer want to do >such  =

> shenanigans?

It may have some use, but who knows from such a short snippet. Maybe the=
  =

original pointer was only a local temporary variable?

> Q2 - Do I need to deallocate all the pointers in VDFDAT as well as the=
  =

> stand alone pointers?

You need to deallocate all memory, that has been allocated using pointer=
s.  =

It doesn't matter which pointer you will use for that. After the memory =
is  =

deallocated, you can not deallocate it once more, because every other  =

pointer, that pointed there is now undefined and must be nullified befor=
e  =

use.

> Q3 - I don't really understand the following precaution from glen
> "As long as none of the allocated memory contains pointers"
> How can I check for this and what exactly would I be checking for?

If you have some allocatable (or pointer) data structures containing  =

derived types with allocatable components only, the components will be  =

deallocated automatically, when you deallocate the parent (or when the  =

parent is deallocated automatically). This is not the case for pointers.=
  =

You must deallocate the components inside yourself first.


-- =

Tato zpr=C3=A1va byla vytvo=C5=99ena p=C5=99evratn=C3=BDm po=C5=A1tovn=C3=
=ADm klientem Opery:  =

http://www.opera.com/mail/

\"Vladim�r Fuka <\"name.surname at <mffDOTcuniDOTcz">> wrote:

(snip)

> If you have some allocatable (or pointer) data structures containing  
> derived types with allocatable components only, the components will be  
> deallocated automatically, when you deallocate the parent (or when the  
> parent is deallocated automatically). This is not the case for pointers.  
> You must deallocate the components inside yourself first.

I hadn't thought of this one before. Will ALLOCATABLEs inside
structures that are allocated through pointers, that is, that
aren't allocatable, be automatically deallocated when the
pointer allocated structure is deallocated?

Even if it is deallocated in another procedure?

That sounds hard to implement.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> I hadn't thought of this one before. Will ALLOCATABLEs inside
> structures that are allocated through pointers, that is, that
> aren't allocatable, be automatically deallocated when the
> pointer allocated structure is deallocated?

Yes. And while you might not have thought about it, others certainly
have when designing the allocatable components feature.
 
> Even if it is deallocated in another procedure?

Another procedure from what? The allocatable in question isn't a local
variable in any procedure. The procedure where pointer allocations
happen is never relevant to pointer targets.
 
> That sounds hard to implement.

Nope. Well, maybe I shouldn't be quite so categorical. Let me soften it
by saying instead "no more difficult than any of the rest of the
allocatable features in the TR and f2003".

Now if a pointer target becomes inaccessible because there are no longer
valid pointers to it, then that's a different question. Maybe that's
what you are thinking about. That's garbage collection issue, which has
nothing directly to do with allocatables; it is quite independent of
whether the structure has allocatable components or not.

But if the pointer target is actually deallocated - by any means - then
yes, any allocatable components in that target will also get
deallocated.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain