In Win32, each process has an associated address space. Portions of address space can be reserved, mapped (or "committed"), or unmapped ("freed") using the functions VirtualAlloc and VirtualFree. (In addition, NT allows one process to allocate memory in another process). File objects can be memory-mapped into the address space using MapViewOfFile. Various levels of protection can be applied to mapped address space using the VirtualProtect functions. On NT, ranges of address can be "locked" into memory using VirtualLock (and unlocked using the obviously named VirtualUnlock). The function VirtualQuery can be used to obtain information on a range of addresses. In practice, most programmers will not need to manipulate memory using these functions as they will use the language's memory management (for example, malloc and free in C) instead. The commonest exception will be mapping files into memory.
There are many ways for automatic memory managers to determine what memory is no longer required. In the main, garbage collection (GC) relies on determining which blocks are not pointed to by any program variables. Some of the techniques for doing this are described briefly below, but there are many potential pitfalls, and many possible refinements.
GC is dead objects. GC also known as automatic M2, is automatic recycling of dynamically allocated memory. GC is a tried and tested M2 technique that has been in use since its invention in the 1950s. GC avoids the need for the programmer to deallocate memory blocks explicitly, thus avoiding a number of problems: memory leaks, double frees, and premature frees. GC can also dramatically simplify programs, chiefly by allowing modules to present cleaner interfaces to each other: the management of object storage between modules is unnecessary.
It is not possible (in general) for a GC to determine exactly which objects are still live. Even if it didn't depend on future input, there can be no general algorithm to prove that an object is live (cf. the Halting Problem). All GCs use some efficient approximation to liveness. In tracing GC, the approximation is that an object can't be live unless it is reachable. In reference counting, the approximation is that an object can't be live unless it is referenced. Hybrid algorithms are also possible. Often the term GC is used narrowly to mean only tracing garbage collection. There are many works on GC.
Microsoft Phoenix provides “a framework” to support "compilation requirements" for runtime CLR GC. It supports:
- Code generation for GC
- Tracking and reporting local object lifetimes for the runtime GC
The runtime GC manages the allocation and release of memory for all managed programs. Each time a managed program creates an object, the runtime allocates memory for the object. Eventually, however, repeated allocations stretch memory resources and the runtime Garbage Collector performs a collection so that it can release some memory. The Garbage Collector can release any memory that is no longer used by the running program. The compiler helps identify the set of managed objects that are still in use by the method at a collection point, based on information tracked by the GC Tracker and based on code processing points the GC designated as safe for collection. The GC Tracker tracks object lifetimes, and performs the analysis necessary to decide which objects can no longer be accessed.
What about native GC? Like libraries that you have for GC? You can make Phoenix plug-in to inject codes inside your codes. I hope I have time to make a demo for you.