Browse Prior Art Database

Processing For Efficient Triggering Of Soft Real-Time Java Garbage Collection To Optimize Throughput, Latency, And Power Consumed

IP.com Disclosure Number: IPCOM000203697D
Publication Date: 2011-Jan-29
Document File: 2 page(s) / 21K

Publishing Venue

The IP.com Prior Art Database

Abstract

Most garbage collection algorithms perform an entire garbage collection when the Java heap space is exhausted which can result in long periods of garbage collection activity with the application stalled (e.g., 2-3 second pauses). For some applications the blocking of an application is unacceptable (e.g., process control sensors, RFID, VXML, or the SIP protocol). There are various techniques to attempt to mitigate this latency but more needs to be done to reduce it. Metronome (http://doi.acm.org/10.1145/604131.604155) is an IBM garbage collection algorithm whose purpose is to provide deterministic garbage collection latency so that the pauses are reduced, avoiding the long latency delays. >From a high-level view, the metronome garbage collection (GC) algorithm has short time slices that it runs for, which prevents the application from stalling for long periods of time. To prevent the GC activity from consuming a high level of CPU resources, there is a limit to how much CPU is expected to be consumed. This may be accomplished with by metronome garbage collection using the CPU for a pre-specified time slice, and that time is given a maximum percentage of the wall clock time (i.e., a maximum number of time slices per second). Although this approach does reduce the latency, it comes at the cost of more CPU overhead which reduces processing throughput. This cost is multiplied when there is more than one metronome JVM running on the same hardware server (i.e., vertical scaling) which is a standard technique to increase application server capacity. One's intuition would suggest that having the garbage collection always on would provide the best latency reduction but this is actually not true. When the metronome is ON, there is more CPU cost for every variable write that occurs (e.g., updating an existing object's attribute) so the execution cost per transaction is increased. This path increase corresponds to a response time increase as well. Having metronome always on may lead to throughput decreases and response time (latency) increases. Unfortunately, it is not possible to remove this additional cost because it is required to track objects which change while GC activity is going on . A high level view is that a Java Virtual Machine (JVM) can be considered to be running in two states: (1) Metronome GC is on which takes CPU cycles away from the application while dead objects are being collected; and (2) Metronome GC is off so there is no performance penalty but there is no GC activity. Metronome has a simple heuristic to move between the states: when the used heap is more than 50% of the total heap then the Metronome GC is turned on. When the free heap is above 50% (i.e., most of the heap is not used) then there is thought to be no need to GC activity. In practice, this type of trigger results in the GC activity almost always being on which is very inefficient. This results in the GC activity always being on, in most cases, resulting in fairly large power consumption (i.e., at least 25% more power consumption even though there may not be a significant amount of transaction work). This problem cannot be solved by just changing the 50% dirty heap trigger to some bigger number, because it has to be ensured that the GC cycle completes before an out-of-memory situation. Thus, the disclosure describes a method for triggering the metronome GC activity so that it is more efficient.

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

Page 01 of 2

Processing For Efficient Triggering Of Soft Real-Time Java Garbage Collection To Optimize Throughput, Latency, And Power Consumed

The following is a general algorithm for a better garbage collection trigger.

Goals

-- Never run out of memory because an out of memory condition will result in a synchronous garbage collection (GC)
-- Collect the most amount of memory as possible on each garbage collection cycle to be efficient
-- Only start a garbage collection cycle when needed due to additional overhead when a garbage collection cycle has started

Parameters

[circle6]RateOfDeath: Rate of death of the objects. Measured in KBytes / second by the JVM.x.

[circle6]RateOfReclamation:Rate of reclamation of the objects. Measured in KBytes / second by the JVM.

[circle6]CycleTime: Average time for a GC cycle to complete measured by the JVM.

[circle6]RateOfCreation: Rate of object creation: Measured in KBytes / second by the JVM. This is calculated over a long period of time relative to a CycleTime.

[circle6]SafetyMargin: Safety margin. This is a margin of safety specified by the user, as a percentage of the ROC value.

[circle6]CycleGap: Time between cycles when Metronome is not running.

[circle6]InitialHeapFree: Amount of heap free space available for the application or business logic at start-up. The memory that is used by the application.

[circle6]ActualHeapFree: Amount of heap free space available for the application, measured at the end of a
GC cycle.

[circle6]PeakFactor: A multiplier that is used to estimate the largest expected burst of work, as a relative measure of the normal work. For example, 150%

would mean that it is expected the peak

Strategy

-- Maximize CycleGap
-- Minimize CycleTime
-- Minimize SafetyMargin

Simplifying Assumptions

The following assumptions should be true as long term properties but they may deviate during bursts of

work activity:

[circle6]'RateOfDeath' == 'RateOfReclamation'

[circle6]"RateOfRecl...