"Deallocate" does not free the memory used by small matrices or pointers.

[metamaterials]

My code has a problem about deallocation. If the memory occupied by the allocatable matrix/pointer is less or equal to 1 MB, i.e. a 32x32x16x16 4D real matrix, FROTRAN does not free the memory even I deallocate the matrix. However, if I increase the matrix demensions to 32x32x32x16 (2MB), then "deallocate" can successfully free the memory.

My code needs to allocate and then deallocate a huge number of small matrices and pointers, and the memory of occupied by these small matrices and pointers are accumulating there. Does anyone has similar experience or advices for this situation?

Thanks a lot!

[Ron_Green]

Quoting - metamaterials

My code has a problem about deallocation. If the memory occupied by the allocatable matrix/pointer is less or equal to 1 MB, i.e. a 32x32x16x16 4D real matrix, FROTRAN does not free the memory even I deallocate the matrix. However, if I increase the matrix demensions to 32x32x32x16 (2MB), then "deallocate" can successfully free the memory.

My code needs to allocate and then deallocate a huge number of small matrices and pointers, and the memory of occupied by these small matrices and pointers are accumulating there. Does anyone has similar experience or advices for this situation?

Thanks a lot!

There have been discussions on this in the past.

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. In Fortran we don't want C++ like garbage collection running all the time chewing up cycles and hurting performance.

When the program exits, linux is also lazy in freeing those pages - so things like 'top' and vmstat may appear like the memory is still in use even though it's not.

Unless you are running out of space there really is no need to worry about when data is physically freed on the system. If you suspect a leak, try using Valgrind. There are no known memory leaks in the current 11.1 compilers.

ron

[metamaterials]

Hi, Ron,

Thank you for your post!
I did several more testings and found that my code has serious problems and will die even these memory can be reused. The testing is as follows:


Step 1: Allocate 1024 small real pointers each of them has the size of 32x16x16x16, which will totally take 1.2 GB in each processor.

gamma=32*32
beta1=32
beta2=16
beta3=16
beta4=16

allocate(EM_test4(1:gamma))
do tempx=1,gamma
allocate(EM_test4(tempx)%p(0:beta1,0:beta2,0:beta3,1:beta4))
EM_test4(tempx)%p(0:beta1,0:beta2,0:beta3,1:beta4)=0.0_dp
end do


Step 2: Deallocate all these small pointers.
do tempx=1,gamma
deallocate(EM_test4(tempx)%p)
end do
deallocate(EM_test4)

Step 3: Allocate a 1.6GB large matrix
allocate(matrix20(128,128,128,108))
matrix20(1:128,1:128,1:128,1:108)=0.0_dp


After the first step, top shows each processor is occupied by 1.2GB memory; the second step does not change the memory (Your explaination is that the memory can be reused, although it seems not be available); the code can finish the third step (but take long time) and will die after this step. The error is

mpispawn.c:303 Unexpected exit status
Child exited abnormally!
Killing remote processes...DONE


To do the contrast, I double the size of each pointer but half the number, that is:
gamma=32*16
beta1=32
beta2=16
beta3=16
beta4=8

Than, after the first step, I also get 1.2GB memory in each processor, but the second step will clean them up; the third step can be successfully done and the memory is 1.6GB.


All these testings tell me that DEALLOCATION does difference things for large and small matrices/pointers, and the released memory from small matrices/pointers can not be reused successfully. Is this correct? How to overcome this situation?


Thanks!

Ming




Quoting - Ronald W. Green (Intel)

There have been discussions on this in the past.

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. In Fortran we don't want C++ like garbage collection running all the time chewing up cycles and hurting performance.

When the program exits, linux is also lazy in freeing those pages - so things like 'top' and vmstat may appear like the memory is still in use even though it's not.

Unless you are running out of space there really is no need to worry about when data is physically freed on the system. If you suspect a leak, try using Valgrind. There are no known memory leaks in the current 11.1 compilers.

ron

[Ron_Green]

Let's first find where the code is dying. Compile and link with options

-g -traceback

the abort code looks like it's coming from mpiexec or mpirun - is this an MPI code?

Next, try this option:

-heap-arrays

and see if this helps.

Also, how much physical memory is on your system - how much RAM is on the server?