Overview
The basic task of a garbage collector is to identify memory space that the application no longer uses and make it available for future allocations. Determining whether a section of memory is in use is essentially determined by scanning all of the program's memory for the address of that section. Generally, if none are found, it indicates that the program cannot access that section and it is therefore ready for recycling.
This scan is more effective if GC has a priori knowledge of where the application keeps its pointers. Classes provide such information for objects, so GC can concentrate on references within objects. There is normally no equivalent information for runtime structures such as stacks and registers, and so these are scanned conservatively. Any value that looks like a pointer (is within the correct range, for example) is considered to be a pointer.
Conservative scanning is guaranteed to retain all accessible objects, but it provides no promise that all inaccessible ones are discarded. This is because a value GC considers that a pointer may, for example, be an integer, and the memory to which it is construed to point may not be an object at all. The efficiency of a conservative GC is therefore lower than that of an accurate one.
Moreover, to improve memory utilization GC may undertake other tasks, such as compaction, where live objects are moved about. When an object is moved, GC must update all memory locations to which it points. If any of these pointers are conservative, it is not safe to make changes, and therefore the object cannot be moved.
It is seen that conservative scanning reduces the efficiency of the GC and gets in the way of object relocation. Eliminating conservativeness involves maintaining stack and register maps which indicate precisely where pointers are stored in those runtime structures. Such maps must be dynamic and require the cooperation of the compiler and the runtime subsystem. JVMs that have this capability are called "accurate" or "precise".
In the course of this project such maps were generated for most types of frames found on the stacks of the IBM JVM, yielding a reduction of up to 70% in the number of conservatively-identified objects. However, since the total population of such objects is not large (for most benchmarks it is less than 1% of the total number of objects), it was decided that continued effort in this direction was not justified. The project has been suspended until a collector that requires such completely accurate root scanning is developed.
A paper that describes this effort appeared in JVM'01 [3].