Tuesday, October 31, 2006

Paper: "CRAMM: Virtual Memory Support for Garbage-Collected Applications"

CRAMM: Virtual Memory Support for Garbage-Collected Applications
Ting Yang and Emery D. Berger, University of Massachusetts Amherst; Scott F. Kaplan, Amherst College; J. Eliot B. Moss, University of Massachusetts Amherst


Existing virtual memory systems usually work well with applications written in C and C++, but they do not provide adequate support for garbage-collected applications. The performance of garbage-collected applications is sensitive to heap size. Larger heaps reduce the frequency of garbage collections, making them run several times faster. However, if the heap is too large to fit in the available RAM, garbage collection can trigger thrashing. Existing Java virtual machines attempt to adapt their application heap sizes to fit in RAM, but suffer performance degradations of up to 94% when subjected to bursts of memory pressure.

We present CRAMM (Cooperative Robust Automatic Memory Management), a system that solves these problems. CRAMM consists of two parts: (1) a new virtual memory system that collects detailed reference information for (2) an analytical model tailored to the underlying garbage collection algorithm. The CRAMM virtual memory system tracks recent reference behavior with low overhead. The CRAMM heap sizing model uses this information to compute a heap size that maximizes throughput while minimizing paging. We present extensive empirical results demonstrating CRAMM's ability to maintain high performance in the face of changing application and system load.


Blogger agmiklas said...

CRAMM: Virtual Memory Support for Garbage-Collection
Ting Yang * and Emery D. Berger, University of Massachusetts Amherst;
Scott F. Kaplan, Amherst College; J. Eliot B. Moss, University of
Massachusetts Amherst

The memory management component of an OS and the heap-management component of a garbage-collected (GC) run-time environment must co-operate with each other to ensure good performance under all memory loads. In particular, the optimal heap size is a function of both the garbage collection algorithm used and the total amount of memory the operating system is willing to allocate to the process. If the heap is sized too large, portions may get swapped out to disk. This can trigger extreme thrashing during the GC reclamation cycle, since it must typically touch every page used to store the heap. On the other hand, if the heap is sized too small, the GC must be invoked more often than is necessary.

Today's operating systems don't provide enough VM sophistication to support GC run-times effectively when memory-pressures are significant. As a result, current run-times are reactive; they only resize the heap once performance has degraded. In contrast, CRAMM is predictive; it can determine the best heap size and suggest that the run-time adjust it before the system begins to experience performance loss.

CRAMM consists of two components: an extension that sits in the kernel's VM subsystem, and a heap size model that exists in the run-time environment. The kernel-mode component tracks each process's working-set size (WSS): the amount of memory that the process needs so that it does only a small amount of swapping. The model component computes the heap size that would cause the process's WSS to just fit within the maximum amount of memory the operating system is willing to allocate. If the current heap size and the computed optimal heap size differ, the model asks the run-time to adjust the size of the heap. The system can therefore quickly respond to changes in memory-pressure by reducing the size of the heap before it is swapped out, avoiding reclamation triggered thrashing.

CRAMM adds only about 1-2.5% overhead during ordinary test runs where memory is plentiful. In exchange, CRAMM dramatically improves the performance in situations where memory-pressure suddenly increases. In all of the testing scenarios, CPU utilization was kept at or above 91% when using CRAMM. However, unmodified run-time environments
experienced thrashing as memory-pressure increased, causing their CPU usage to drop. In summary, CRAMM helps garbage-collected run-time environments select a heap size that optimizes system performance.

Q: In your paper, you assumed that when using copying garbage collectors, the number of pages used to hold "copied survivors" does not change rapidly. However, it appears that this parameter can change quickly under flash-workloads. Will your system therefore be able to handle flash-loads when the run-time uses copying GCs? (Christ Stewart, University of Rochester)

A: We keep track of the CS value from one invocation of the GC to the next, and apply a smoothing function. The maximum value ever seen for the CS value is weighted more heavily to ensure that we don't underestimate this parameter.

11:42 AM  

Post a Comment

<< Home