Java and Javascript Archive

Garbage Collection Techniques

• How You Can Test Electronic Components

Garbage Collection designates a set of techniques used by Java VM for automatic memory reclamation; those familiar with these techniques can skip this section. Garbage Collection generally consists of three steps: (1) mark, (2) collect, and (3) clean-up. The mark step finds the objects that need to be retained. The collect step removes unused objects. The clean-up step returns the reclaimed memory to the pool of free memory (i.e., return to a usable state). The OracleJVM memory manager uses a set of GC techniques for its various memory structures (listed in Table 2.1), including the generational GC, mark-sweep GC, and copy GC.

Generational GC

Generational GC is a technique that segregates memory areas by their age (i.e., generations). Allocations happen in the most recent area. When an area is full, a collector is used to "move" the live objects to the next older area (hence, the term generational). Different collection algorithms may be used across generations. As a result, most objects are reclaimed upon the first GC, resulting in many inexpensive GCs instead of fewer large ones.

Mark-sweep GC

A mark-sweep GC consists of two phases: (1) the mark phase (garbage detection) and the (2) sweep phase (Garbage Collection). The sweep phase places the "garbaged" memory on the freelists. The allocation is serviced out of the freelists. Lazy sweeping is a variation technique that marks objects normally, but, in the sweep phase, leaves it up to the allocation phase to determine whether the marked objects are live (no need to reclaim) or not (can be reclaimed), rather than sweeping the object memory at that time.

Copy GC

Copy GC consists of recursively copying objects, referenced by root objects, into an empty region of the object memory. It combines marking and compacting into one operation. This technique is very efficient when most of the objects need to be reclaimed—which is the case most of the time.

Reference-counting GC

In reference-counting GC, each object stores a count of the number of references to it. This count is incremented every time a reference to that object is stored and decremented every time a reference to that object is overwritten. The object is reclaimed when the count reaches zero.

Self-tuning GC

Starting with Oracle 9i Release 2, the Garbage Collector automatically and dynamically adjusts the threshold at which the GC is triggered; for most applications, you don't have to play with GC thresholds, using OracleRuntime.getSessionGCThreshold() and OracleRunt-ime.setSessionGCThreshold(). In Oracle Database 10g Release 2, the GC supports PGA_AGGREGATE_TARGET and a smoother memory growth.

Supporting PGA_AGGREGATE_TARGET: The DBA or database developers with DBA privileges can set the PGA_AGGREGATE_TARGET13 parameter, which will instruct the GC to trade memory for speed and vice versa. The values differ as follows:

• Low values optimize memory at the expense of execution speed. In other words, if the only active Java thread at the end of the top-level call is the main thread (i.e., there are no user threads), then perform a full GC of oldspace to free up memory, irrespective of the type of server (dedicated or shared). This results in optimizing the PGA space usage, much like the end-of-call migration, which happens systematically in pre-10g and only in shared server mode in 10g.
• High values optimize the execution speed at the expense of memory. In other words, state migration is not performed at the end of the call, when in dedicated mode.

1. See the Oracle Database Performance Tuning Guide for a more detailed discussion.
2. Pre-I0g Database releases, OracleJVM kills any remaining live threads at the end of the call.

Smoother Memory Growth: In Oracle database 10^ Release 2, the clean-up and growth of the memory space used for holding long-lived or large objects (i.e., Oldspace) is smoother. In previous releases, the growth of Oldspace was too aggressive, resulting in that a user who allocates a lot of objects and then drops these ends up with a large unused memory space. In 10g Release 2, Oldspace grows only if the growth is inversely proportional to the amount of space freed. In other words, Oldspace cannot grow more than 100 percent of its current size.

0 0