Garbage collection

All .NET objects are allocated in memory that is controlled by the system garbage collector. This means that C# programmers do not need to delete (DEALLOCATE) objects that they have created. When the memory allocated to a program runs low, the garbage collector determines those objects that are redundant and reclaims the associated memory. The garbage collector occasionally compacts memory to reduce excessive fragmentation. This involves adjusting pointer information and is invisible to the user.

Automatic garbage collection is not feasible with older languages like Fortran. This means that you must use ALLOCATE and DEALLOCATE in accordance with the Fortran 95 standard. In other words, in order to avoid memory leakage, every ALLOCATE must have a corresponding DEALLOCATE unless,

1) the ALLOCATEd variable is local to a routine and is not SAVEd and is not a TARGET (this is because Fortran 95 provides for automatic deallocation when a local variable goes out of scope) or

2) the execution of the program is about to terminate.

Note also that, although NEW@ is used to ALLOCATE memory for a .NET object, there is no equivalent (for objects) to DEALLOCATE. This means that in cases where deallocation is necessary, you must write your code in such a way as to enable the system garbage collector to do the deallocation automatically. Automatic garbage collection will only take place if the variable is local to a routine or is stored in a module (all COMMON/EQUIVALENCE variables, all arrays, and all ALLOCATED non-local variables are placed in memory that is not subject to garbage collection).

FTN95 uses .NET objects to implement Fortran input and output (and these objects are subject to automatic garbage collection). Otherwise FTN95 does not use .NET garbage collection except for OBJECTs created by the user within the Fortran program.