A few points:
The efficient management of memory is application dependent. The most
efficient algorithm is different for applications:
that continually generating and discard small blocks of memory
that generates large blocks and discards them at rare times
that never discards memory
that initially generates a large number of small objects and gradually
discards them
an application that episodically generates large numbers of objects and then
gradually discards them
These efficiency differences apply not only to garbage collection, but also to
standard allocation/deallocation, which must also use some algorithms to
interface with the OS (or provided by the OS). It is not unknown for standard
allocation/deallocation to have some surprising inefficiencies for some
applications. A garbage collector, by eliminating some of the standard
allocation calls, can be more efficient than standard accesses for many
applications. However, as garbage collection is a more complex process than
standard allocation, it is potentially even more variable in its performance.
The ideal would be a compiler that optionally provides any one of several
garbage collection algorithms, but I don't know of any systems (I suspect
there are a few non-fortran experimental ones) that provide that option. Also
be aware that sometimes raw efficiency alone is not the only consideration.
While rare for Fortran, applications that interface with users often want a
collection scheme that operates frequently, rather than doing everything at
once, which can stop user interactions for significant periods. Such systems
typically rely on the less efficient and robust reference counting although
some (complicated) true garbage collecting algorithm's provide comparable
performance characteristics without any danger of leakage.
Then again there is the (possibly apochrypal(?)) missile guidance system that
leaked memory, but was budgeted with twice the memory necessary to hold the
leakage generated on its longest possible flight. Garbage leaks, even when
they occur are not always a problem.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|