The causes of bloat, the limits of health

MitchellNick,; SevitskyGary,

doi:10.1145/1297105.1297046

Cited by 36 publications

(42 citation statements)

References 17 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…High-level languages abstract memory management and object layout to improve programmer productivity, usability, and security, but abstraction usually costs. Mitchell and Sevitsky study bloat, spurious memory consumption caused by careless programming [22]. A shocking fraction of the Java heap is bloat, motivating the need for space savings.…”

Section: Read and Write Barriersmentioning

confidence: 99%

Z-rays

et al. 2010

View full text Add to dashboard Cite

Arrays are the ubiquitous organization for indexed data. Throughout programming language evolution, implementations have laid out arrays contiguously in memory. This layout is problematic in space and time. It causes heap fragmentation, garbage collection pauses in proportion to array size, and wasted memory for sparse and over-provisioned arrays. Because of array virtualization in managed languages, an array layout that consists of indirection pointers to fixed-size discontiguous memory blocks can mitigate these problems transparently. This design however incurs significant overhead, but is justified when real-time deadlines and space constraints trump performance.This paper proposes z-rays, a discontiguous array design with flexibility and efficiency. A z-ray has a spine with indirection pointers to fixed-size memory blocks called arraylets, and uses five optimizations: (1) inlining the first N array bytes into the spine, (2) lazy allocation, (3) zero compression, (4) fast array copy, and (5) arraylet copy-on-write. Whereas discontiguous arrays in prior work improve responsiveness and space efficiency, z-rays combine time efficiency and flexibility. On average, the best z-ray configuration performs within 12.7% of an unmodified Java Virtual Machine on 19 benchmarks, whereas previous designs have two to three times higher overheads. Furthermore, language implementers can configure z-ray optimizations for various design goals. This combination of performance and flexibility creates a better building block for past and future array optimization. on discontiguous array optimization choices. Our experimental results on 19 SPEC and DaCapo Java benchmarks show that our best z-ray configuration adds an average of 12.7% overhead, including a reduction in garbage collection cost of 11.3% due to reduced space consumption. In contrast, we show that previously proposed designs have overheads two to three times higher than z-rays.Z-rays are thus immediately applicable to discontiguous arrays in embedded and real-time systems, since they improve flexibility, space efficiency, and add time efficiency. Since the largest object size determines heap fragmentation and pause times, and first-N increases it by N, some system-specific tuning may be necessary to achieve particular space and time design goals. We believe zrays may also help to ameliorate challenges in general-purpose multicore hardware trends. For example, multicore hardware is becoming more memory-bandwidth limited because the number of processors is growing much faster than memory size. Lazy allocation and copy-on-write eliminate unnecessary, voluminous, and bursty write traffic that would otherwise slow the entire system down. Z-rays not only make discontiguous arrays more appealing for real-time virtual machines, but also make them feasible for general-purpose systems.Our results demonstrate that z-rays achieve both performance and flexibility, making them an attractive building block for language implementation on current and future architectures.

show abstract

Section: Read and Write Barriersmentioning

confidence: 99%

Z-rays

et al. 2010

View full text Add to dashboard Cite

show abstract

“…Modeling and characterization. Mitchell and Sevitsky categorize fields by the role they play in an object (header, pointer, null, primitive), and categorize objects by the role they play in a data structure (head, array, entry, contained) [18]. These measures together with scaling formulas predict the heap data reductions of manual program changes.…”

Section: Related Workmentioning

confidence: 99%

“…Researchers have characterized Java memory usage patterns [5,11,18], but do not study memory savings opportunities. A number of researchers propose and measure specific compression approaches [2,4,7,8,9,14,17,19,22,23,30].…”

Section: Introductionmentioning

confidence: 99%

No bit left behind

Sartor

Hirzel

McKinley

2008

Proceedings of the 7th International Symposium on Memory Management

View full text Add to dashboard Cite

On one hand, the high cost of memory continues to drive demand for memory efficiency on embedded and general purpose computers. On the other hand, programmers are increasingly turning to managed languages like Java for their functionality, programmability, and reliability. Managed languages, however, are not known for their memory efficiency, creating a tension between productivity and performance. This paper examines the sources and types of memory inefficiencies in a set of Java benchmarks. Although prior work has proposed specific heap data compression techniques, they are typically restricted to one model of inefficiency. This paper generalizes and quantitatively compares previously proposed memorysaving approaches and idealized heap compaction. It evaluates a variety of models based on strict and deep object equality, field value equality, removing bytes that are zero, and compressing fields and arrays with a limited number and range of values. The results show that substantial memory reductions are possible in the Java heap. For example, removing bytes that are zero from arrays is particularly effective, reducing the application's memory footprint by 41% on average. We are the first to combine multiple savings models on the heap, which very effectively reduces the application by up to 86%, on average 58%. These results demonstrate that future work should be able to combine a high productivity programming language with memory efficiency.

show abstract

“…It is therefore not surprising that recent studies [22] have shown that in some production systems, the utilization of collections might be as low as 10%, that is, 90% of the space consumed by collections in the program is overhead.…”

Section: Introductionmentioning

confidence: 99%

“…PLDI'09, June 15-20, 2009 Existing profilers ignore collection semantics and memory layout, and aggregate information based on types. Offline approaches using heap-snapshots (e.g., [21,22]) lack information about access patterns, and cannot correlate heap information back to the relevant program site.…”

Section: Introductionmentioning

confidence: 99%

Chameleon

2009

View full text Add to dashboard Cite

Languages such as Java and C#, as well as scripting languages like Python, and Ruby, make extensive use of Collection classes.A collection implementation represents a fixed choice in the dimensions of operation time, space utilization, and synchronization. Using the collection in a manner not consistent with this fixed choice can cause significant performance degradation.In this paper, we present CHAMELEON, a low-overhead automatic tool that assists the programmer in choosing the appropriate collection implementation for her application. During program execution, CHAMELEON computes elaborate trace and heap-based metrics on collection behavior. These metrics are consumed on-thefly by a rules engine which outputs a list of suggested collection adaptation strategies. The tool can apply these corrective strategies automatically or present them to the programmer.We have implemented CHAMELEON on top of a IBM's J9 production JVM, and evaluated it over a small set of benchmarks. We show that for some applications, using CHAMELEON leads to a significant improvement of the memory footprint of the application.

show abstract

The causes of bloat, the limits of health

Cited by 36 publications

References 17 publications

Z-rays

Z-rays

No bit left behind

Chameleon

Contact Info

Product

Resources

About