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.
2.
3.
4.
5.
Introduction
Related work
Proposed architecture
Experiment and results
Conclusion and future work
Introduction
Introduction
Mobile/Wireless Communication
Service Providers (network activated)
Client and server models
Email service
Service Archive
Web service
Service
Management
Component
Mobile
Network
Services
Repository
Mobile
commerce
Audio, video
animation
Introduction
Main Issue of
Java mobile/wireless computing
• Many application demands more memory
• Mobile/wireless devices suffer from their
small memory
Introduction
Related work
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)
6. Java heap memory compression
[Lo and KATO ’03], [Chen et al. ’03], [KATO and Lo ’04]
The proposed architecture consists of:
Java Virtual Machine (JVM) core
Memory management module
Cache unit Delayed buffer
Delayed buffer is full?
Address Lookaside buffer
Compressing unit
Decompressing unit
Local object accessed
(compressed form)
Compressed heap
ALB table
accessed
stored
Store compressed block
The Proposed Architecture
Goals
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
Features
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.
execution
 Different
, [Rippen
Different from
from classfile
constant [Pugh]
per-object
pool
[Chen
et al. 03]
et al.]
bytecode
[Clausen
al.],Krintz]
[Evans and Fraser]
native code
[zhangetand
The Proposed Architecture
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.
Java VM core
Memory management module
New local object created
(uncompressed form)
Cache unit
Delayed buffer
Decompressing unit
Delayed buffer is full?
Compressed heap
ALB table
Compressing unit
stored
Store compressed block
Java VM core
Memory management module
Remote object created and accessed
(compressed form)
Cache unit
Delayed buffer
Decompressing unit
Delayed buffer is full?
Address Lookaside buffer
Compressed heap
ALB table
Compressing unit
stored
Store compressed block
Java VM core
Memory management module
Cache unit
Delayed buffer
Decompressing unit
Compressed form
Delayed buffer is full?
Address Lookaside buffer
Compressed heap
ALB table
Compressing unit
accessed
stored
Store compressed block
The Proposed Architecture
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 mechanism
From the caching unit
The Proposed Architecture
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
WK algorithms
Coding format <tag> [4 bits] [10 bits] [22 bits]
Dictionary index
Match
type
high ZERO
EXACT
low
upper
Coding specification
< 0x0 >
< 0x1 >< 4 bits dictionary index >
PARTIAL < 0x2 >< 4 bits dictionary index >< 10 low bits>
low
MISS
< 0x3 > < 32 bits literal pattern >
WK Example
Input
A0129FAE
1111 1010 1110
partial
1100 1010 1110
1101 1010 1110
no match
0000 1010 1110
exact
1111 1010 1110
Dictionary
1
2
3
4
output
A0129CAE
A0129DAE
A01290AE
A0129FAE
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 gc
spaceEfficiency = ----------------- W comp+gc : watermark on
W comp+gc the proposed architecture
(compression + gc)
timeEfficiency
T gc : total execution time
(including gc time) on the
T gc
= ---------------- original architecture
T comp+gc
T comp+gc : total execution
time (including comp. and
gc times) on the proposed
architecture
Experiment and results
Summaries of Experiment Results
Application
EmailViewer
Space
Efficiency
2.05
• Space efficiency 2.0
– Reduce heap memory demand
to 50% or more on average
1.80
– Independent of the size of Java
dynamic heap
256KB heap
HTTP demo
64KB heap
Stock
2.50
64KB heap
Audiodemo
2.20
64KB heap
Manyballs
32KB heap
2.09
– 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
Application
EmailViewer
time
Efficiency
0.99
256KB heap
HTTP demo
No time overhead
1.00
64KB heap
Stock
0.99
64KB heap
Audiodemo
• Time efficiency 1.0
– HTTP demo, Audio demo,
many balls
1.00
Good data and code locality
and less invocation of garbage
collection
• Time efficiency 0.99
– Stock and EmailViewer
64KB heap
Manyballs
32KB heap
1.00
Time overhead is within 1 %
The use of local database and
disk accesses?
Experiment and results
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.
On-going work
Tuning speed
Future work
Studying the impact of the compressed
heap on remote object
Questions
URL paper : ieee library
6 pages, but with Dr. Lo’s permission