Tuning Garbage Collection in an Embedded Java Environment

transcript

G. Chen, R. Shetty,

M. Kandemir,

N. Vijaykrishnan, M. J. Irwin

Microsystems Design Lab

The Pennsylvania State University

M. Wolczko

Sun Microsystems, Inc.

Objectives

Investigate the role of GC in energy consumption of energy-aware systems

Find energy consumption improvements based on GC mechanism

Roadmap

Background & Motivation KVM GC and Parameters Experiments setup Energy Characterization and

Optimization Conclusions

Why Java ?

Increasing popularity of Java in portable devices.• portability• natural for web based applications

Estimated number of Java enabled devices in 2005: 721 million• cell phones, PDAs, pagers etc.

Characteristics of Embedded Devices

Small memory capacity Requirements of low energy

consumption more (soft real-time, long duration sessions etc.)

How to incorporate the change ? Application independent - by adapting

JVM to target requirements

Electrical Characteristics

Devices are required to reduce size and increase performance

Technological Solution: 10 Technology Price: higher energy consumption

Memory Energy Consumption

Significant part of overall energy consumption

Memory types: Banked-RAM, ROM, Cache

Characteristics: Dynamic, Leakage, Shutdown

Advances in miniaturization result in higher energy leakage

Why GC ?

Independent of application, impacts memory management

May be easily controlled May be used to shutdown memory

KVM GC’S

Mark & Sweep (M&S)• Simple

M&S + Compaction (M&C)• Handles fragmentation• 2KB chunks reserved for ‘Permanent data’ not

included in GC Energy tradeoff:

• Simple wastes more memory• complicated - consumes more

More on M&C

Compaction occurs• No big enough entry in free list• When a need for more permanent memory

arises Until compaction - garbage-occupied

memory is considered live

Memory Wasted Waiting for GC

Experiment Setup - “Hardware”

microSparc-IIep embedded processor 100Mhz, 32bit, 5-stage pipeline On chip memories: ROM, RAM, Cache

Experiment Energy Models

Simulate KVM executing applications Accurately simulate hardware energy

consumption Cache modeled as SRAM Scale parameters to 10 Technology Assume large leakage-energy

Experiment Setup - Banked Memory

Assume shutdown and turn-on capability of 16KB banks

Simulate Turn-on cost (350 cycles)

Experiment Setup - Benchmarks

Core heap(leakage) heap(dynamic)

Runtime Stack(leakage) Runtime Stack(dynamic) ROM(leakage)

ROM(dynamic)

Introducing Mode Control

Shutting down unused memory banks Implemented on heap and stack

The price - the turning on / off process, is negligible

Impact of Mode Control (M&S)

Heap Runtime Stack

Increasing Frequency of GC

Until garbage collection, memory banks might be on only storing garbage

Increasing GC Frequency will help get rid of the garbage more quickly

Tradeoff:Energy saved versus Energy spent on GC

Controlling GC Frequency

In the experiment: “After K calls to the allocator”

In real implementation the policy should be f(memory allocated), or simply before turning on a new memory bank.

Impact of GC Frequency

10 40 75 100 250 Out of MemoryMode Control

The Cost of Increasing GC Freq

Mode Control 10 40 75 100 250

GC Frequency - Conclusions

Dependent on memory usage scheme Don’t exaggerate ! Frequency of ~70 gives good results Application dependently determining the

GC frequency could be an optimal(the article is already published...)

Modifying Object Allocation Style

M&S algorithms maintain a ‘free list’ More energy sensitive schemes: Active Bank

• free list per block• Allocate first from active banks

Active Bank+• If cannot allocate from an already active

bank - run GC

Impact of Object Allocation Style

First Active Active+GCMode Control

Impact of Object Allocation Style Explained

Active Bank ~ Mode Control• Coherent with observation that the younger

die first• ‘Permanent’ objects occupy the lower part

of heap. The higher part is usually cleaned during GC

Impact of Object Allocation Style Explained

Active Bank + is better• Increases frequency of GC• reduces probability of turning on a new

memory bank• Permanent objects are likely to be

allocated more densely

Compaction

Compaction may decrease number of active memory banks

Tradeoff:Energy spent on compaction versusreduction of memory energy consumption

Impact of Default Compaction

No Compact Compact

Impact of Default Compaction

Disappointing... Better compaction schemes ?

• M&C+ Perform compaction after each GC• M&C2 Different compaction algorithm

M&C2 versus M&C• cheaper marking and updating• more overhead per allocation

Impact of Compaction Schemes

Mode Control M&C M&C2 M&C+

Impact of Compaction - Conclusions

Compaction does not achieve great savings

Compaction though cannot be omitted• more memory will be needed for

application due to fragmentation

Impact of Cache

Reduces access to main memory:• Heap energy drops to 23% of overall

energy Cache itself is a significant energy

consumer

Impact of GC Schemes in Presence of Cache

Conclusions

The combination of hardware mechanisms to lower energy leakage and software controlling it, may substantially reduce energy consumption

Saving may be achieved without application awareness

Conclusions

GC mechanisms, with minor modifications, can help reach the energy saving goal

Mode Control, Allocation strategy, GC frequency are the most important.

Compaction is usually necessary, its implementation affects energy consumption

Tuning Garbage Collection in an Embedded Java Environment

Documents