impact of java compressed heap on mobile/wireless communication mayumi kato and chia-tien dan lo...
TRANSCRIPT
Impact of Java Compressed Heap on Mobile/Wireless Communication
Mayumi KATO and Chia-Tien Dan Lo (itcc’05)
Department of Computer Science, University of Texas at San Antonio
{mayumik, danlo}@cs.utsa.edu
Speaker : Mayumi KATO
Outline
1. Introduction
2. Related work
3. Proposed architecture
4. Experiment and results
5. Conclusion and future work
Mobile Network
Mobile Network
Service Providers (network activated)
ServiceManagement Component
ServicesRepository
Service Archive
Email service
Web service
Mobilecommerce
Audio, videoanimation
Mobile/Wireless Communication Client and server models
Introduction
Introduction
Main Issue of Java mobile/wireless computing
Introduction
• Many application demands more memory
• Mobile/wireless devices suffer from their small memory
Related work
6. Java heap memory compression [Lo and KATO ’03], [Chen et al. ’03], [KATO and Lo ’04]
Introduction
1. Java classfile compression [Pugh’99]
(small file, but the same info. as of a Jar file: eliminate redundancy)
2. Java bytecode factorization [Clausen et al.’00]
(extended instruction set, macro instruction definitions from CAP file)
-- bytecode instructions, replace common instruction sequences
3. Java compact bytecode instructions [Evans and Fraser’01]
(grammar based method, G a parse tree derivation of the program)
-- compression demands a minimum length derivation of the program
4. Java on-the-fly constant pool compaction [Rippert et al. ’04]
(class loading, eliminate constant pool entry if not referenced)
5. Java profile-driven code unloading [Zhang and Krintz ’04]
(JIT, unloading methods “has-not-been-used recently)
stored
accessed
Compressed heap
Decompressing unit
Compressing unit ALB table
Cache unit Delayed buffer
Java Virtual Machine (JVM) coreMemory management module
Store compressed block
Delayed buffer is full?(compressed form)
Local object accessed
The proposed architecture consists of:
Address Lookaside buffer
1. Reduce memory demands
2. Allow large client applications to run on mobile/wireless embedded devices
3. Minimize the number of active memory banks, and power off unused banks to eliminate the leakage current in memory system
The Proposed Architecture
Goals
The hardware de/compression engines are integrated into Java virtual machine (software) to de/compress a group (a page) of local and remote objects during Java execution.
a group (a page)
executionduring Javaobjects
Different from constant pool [Rippen et al.]
native code [zhang and Krintz]
Different from classfile [Pugh], bytecode [Clausen et al.], [Evans and Fraser]
Different from per-object [Chen et al. 03]
Features
local and remote
Assumptions
1. Object is created either locally or remotely
2. Objects that come over the Internet have been compressed at the sending side
3. Objects that newly created inside the JVM are not compressed.
The Proposed Architecture
stored
Compressed heap
Decompressing unit
Compressing unitALB table
Cache unitDelayed buffer
New local object created (uncompressed form)
Java VM coreMemory management module
Store compressed block
Delayed buffer is full?
stored
Compressed heap
Decompressing unit
Compressing unitALB table
Cache unitDelayed buffer
Remote object created and accessed (compressed form)
Java VM coreMemory management module
Delayed buffer is full?
Store compressed block
Address Lookaside buffer
stored
accessed
Compressed heap
Decompressing unit
Compressing unitALB table
Cache unit Delayed buffer
Java VM coreMemory management module
Delayed buffer is full?
Store compressed block
Compressed form
Address Lookaside buffer
Garbage collection
• Java memory management system– Garbage collection mechanism
• Mark, sweep, compaction phases
• We redesigned it to handle compressed objects– Mark, similar to the original version– Sweep and compaction phases
• Migrated into de/compression modules• Delayed until de/compression is invoked
The Proposed Architecture
Garbage collection mechanismThe Proposed Architecture
From the caching unit
In-memory compression algorithms
• Popular compression algorithm LZ family– Designed for human text– Not suitable for data in memory/cache because of its
regularity modeling
• Most in-memory/cache data– Word aligned integers and pointers– Contains many repeating zero values
• We use Wilson-Kaplan (WK) compression family– A dictionary-based algorithm
The Proposed Architecture
WK algorithms
Coding format <tag> [4 bits] [10 bits] [22 bits]
Dictionary index low upper
Match
type
Coding specification
ZERO < 0x0 >
EXACT < 0x1 >< 4 bits dictionary index >
PARTIAL < 0x2 >< 4 bits dictionary index >< 10 low bits>
MISS < 0x3 > < 32 bits literal pattern >
high
low
WK Example
A0129FAE
1111 1010 1110A0129CAE A0129DAEA01290AEA0129FAE0000 1010 1110
1111 1010 1110
1101 1010 1110
1100 1010 1110
no match
partial
exact
InputDictionary
12
43
output 01 0100
Experiment and Results
1. Examined compression techniques on mobile/wireless devices (CS LAN)
2. Show their impact using space and time efficiencies
W gc : watermark on the
original architecture (gc)
W comp+gc : watermark on
the proposed architecture (compression + gc)
T gc : total execution time (including gc time) on the original architecture
T comp+gc : total execution time (including comp. and gc times) on the proposed architecture
W gc
spaceEfficiency = ----------------- W comp+gc
T gc
timeEfficiency = ---------------- T comp+gc
Summaries of Experiment Results
Application Space Efficiency
EmailViewer
256KB heap2.05
HTTP demo 64KB heap
1.80
Stock
64KB heap2.50
Audiodemo 64KB heap
2.20
Manyballs 32KB heap
2.09
• Space efficiency 2.0– Reduce heap memory demand
to 50% or more on average
– Independent of the size of Java dynamic heap
– Half of the memory banks for Java heap may never be turned on
– More than 50% of the memory leakage can be saved
Experiment and results
Experiment and results
• Time efficiency 1.0– HTTP demo, Audio demo,
many balls
No time overhead
Good data and code locality and less invocation of garbage collection
• Time efficiency 0.99– Stock and EmailViewer
Time overhead is within 1 %
The use of local database and disk accesses?
Application time Efficiency
EmailViewer
256KB heap0.99
HTTP demo 64KB heap
1.00
Stock
64KB heap0.99
Audiodemo
64KB heap1.00
Manyballs
32KB heap1.00
Conclusion and Future Work
We have seen the impact of Java compressed heap.
Results show
The compressed heap– Effective– Ensure small memory footprints for mobile/wireless
application with any memory demand.
Experiment and results
On-going work
Tuning speed
Future work
Studying the impact of the compressed heap on remote object
Questions
URL paper : ieee library6 pages, but with Dr. Lo’s permission