Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Heuristic Garbage Collection

IP.com Disclosure Number: IPCOM000013453D
Original Publication Date: 2001-Apr-16
Included in the Prior Art Database: 2003-Jun-18
Document File: 3 page(s) / 44K

Publishing Venue

IBM

Abstract

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

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 47% of the total text.

Page 1 of 3

Heuristic Garbage Collection

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

    Average Size of objects created Frequency of the object creation Frequency of objects going out of scope. Frequency of explicit requests for Garbage Collections and finalization Metrics is a large area and the potential is there to generate more. Each application has a different set of behaviours. A graphical application may create a lot of graphical objects at start up. During execution it may not create many objects. This has a different behaviour from a server program. This is long running and may have a more even object creation cycle.

    Garbage Collection itself has a number of parameters (reflected by the metrics above). By changing the values of these, the performance of applications can be enhanced. It may be possible to modify some of the algorithms used by GC. An analogy is sorting. For example, for a list of 100 items it may be better to use a simple bubble sort. A list of a million items would be better sorted by QuickSort. If some metrics were available about the data, a different sort may be applicable. For example if the data was already partially sorted, as opposed to random

    Studies on Garbage Collection have generated a large selection of algorithms. As suggested above, different algorithms are better in certain circumstances. A typical example is where a new object is fitted into memory. Is it better to fit it in the first available space or find a better space that just fits the object. Metrics based on the

1

Page 2 of 3

average and distribution of object sizes c...