Browse Prior Art Database

Heuristic Garbage Collection Disclosure Number: IPCOM000013453D
Original Publication Date: 2001-Apr-16
Included in the Prior Art Database: 2003-Jun-18

Publishing Venue



One of the differentiators of Java* Technology is performance and one of the pressures is the requirement to be suitable for a variety of different applications. These range from applications such as the WebSphere suite to client based applications/applets. This means that the JVM has to be "everything to everybody", Such pressures inevitably result in compromises being made. One typical area in which performance is critical is the Garbage Collector. This is an inherently complex implementation requiring good stability accurate functionality. The number of times the Garbage Collection cycle is invoked makes it critical that it has good performance. Its central location in the Virutal Machine also means that its implementation needs to be stable. There are many metrics available that can be used to monitor the Garbage Collection cycle and collect information. Examples are Number of Finalizers to run Number of Objects to collect Fragmentation of Memory Amount of Memory Available Frequency of Garbage Collection Cycles Degree of Work required during Garbage Collection cycles (eg, heap compaction/ expansion) Some of these measures are easy to obtain from the current implementations. Indeed the JVM will itself use some form of metrics to decide when to run the Garbage Collection cycles. Extra information can be obtained about the application itself. Current implementations of the JVM do not have these metrics. Such examples could be