fortran deallocate array but not released in OS

Question

I have the following question:how do I deallocate array memory in type? Like a%b%c, how do I deallocate c? the specific problem is(The compiler environment I tried are gfortran version gcc4.4.7 and ifort version 18.0.1.OS:linux):

 module grist_domain_types

     implicit none

     public :: aaa 

      type bbb 
         real (8), allocatable   :: c(:)
      end type bbb 

      type aaa 
         type(bbb),  allocatable :: b(:) 
      end type aaa 

 end module grist_domain_types

 program main

    use grist_domain_types
    type(aaa) :: a
    integer(4) :: time,i
    time=20

    allocate(a%b(1:100000000))
    call sleep(time)!--------------1

    do i=1,100000000
        allocate(a%b(i)%c(1:1))
    enddo
    call sleep(time)!--------------2

    do i=1,100000000
        deallocate(a%b(i)%c)
    enddo
    call sleep(time)!--------------3

    deallocate(a%b)
    call sleep(time)!--------------4


 end program

First,"gfortran main.F90 -o main" to compile the program, and run this program. Then I use top -p processID to see memory. When the program is executed to 1, the memory is 4.5G. When the program is executed to 2, the memory is 7.5G. When the program is executed to 3, the memory is also 7.5G(but I think is 4.5G). When the program is executed to 4, the memory is 3G(I think is 0G or close to 0G). So deallocate(a%b(i)%c) does not seem to work. However, I use valgrind to see memory. the memory of this program is all deallocate...I used ifort and gfortran. This problem happens no matter which compiler I use. How to explain this question? I allocate many c array in this way,the program will finally crash due to insufficient memory. And how to solve it?

Answer 1

I modified your program ( to see where it was up to ) and ran on Windows 7 / gFortran 7.2.0. It does not demonstrate the memory retention as you report, as memory reverts to 13 mb. Contrary to my comment, memory demand did not change during initialisation of c.

   module grist_domain_types

     implicit none

     public :: aaa 

      type bbb 
         real (8), allocatable   :: c(:)
      end type bbb 

      type aaa 
         type(bbb),  allocatable :: b(:) 
      end type aaa 

   end module grist_domain_types

   program main

    use grist_domain_types
    type(aaa)  :: a
    integer(4),parameter :: million = 1000000
    integer(4) :: n = 100*million
    integer(4) :: time = 5, i, pass

  do pass = 1,5
    write (*,*) ' go #', pass

    allocate(a%b(1:n))
    write (*,*) 'allocate b'
    call sleep(time)!--------------1
    write (*,*) ' go'

    do i=1,n
        allocate(a%b(i)%c(1:1))
    enddo
    write (*,*) 'allocate c'
    call sleep(time)!--------------2
    write (*,*) ' go'

    do i=1,n
        a%b(i)%c = real(i)
    enddo
    write (*,*) 'use c'
    call sleep(time)!--------------2a
    write (*,*) ' go'

    do i=1,n
        deallocate(a%b(i)%c)
    enddo
    write (*,*) 'deallocate c'
    call sleep(time)!--------------3
    write (*,*) ' go'

    deallocate(a%b)
    write (*,*) 'deallocate b'
    call sleep(time)!--------------4
  end do

    write (*,*) ' done : exit ?'
    read (*,*) i

   end program

edit: I have given the test a repeat with do pass... to repeat the memory demands. This shows no memory leakage for this Fortran program. I use Task manager to identify memory usage, both for this program and the O/S. Your particular O/S and Fortran compiler may be different.

Answer 2

Take a look at this post from the Intel forum. There are 2 important information in there:

1. (From Doctor Forran):

   When you do a DEALLOCATE, the memory that was allocated returns to the pool used by the memory allocator (on Linux and OS X this is the same as C's malloc/free). The memory is not released back to the OS - it is very rare that this would even be possible. What often happens is that the pattern of allocations and deallocations causes virtual memory to be fragmented, so that while the total available space may be high, there may not be sufficient contiguous space to allocate a large item. Unlike with disks, there is no way to "defrag" memory.

2. (From Jim Dempsey)

   See if you can deallocate the memory in the reverse order in which it was allocated. This can reduce memory fragmentation.

You may also refer to this other Intel post:

During the program run, the Fortran runtime library will manage your heap. Yes, if data is DEALLOCATED, the runtime may choose to wait to release that memory. It's an optimization - if you do another ALLOCATE with the same size it will just reuse those pages. If the heap starts to run low, it will do some collection but not until it's absolutely necessary.

Also, let me add something: Check if there aren't other objects dynamically created in scope, like automatic arrays or temporal array copies. That could be demanding memory that may be freed only when they get out of scope.

Summing up, even if 'top' says the memory is still in use, you should start to worry only if your program starts to crash or if Valgrind shows something wreid.