Impact of Java Compressed Heap on MobileWireless Communication

1
Impact of Java Compressed Heap on
Mobile/Wireless Communication

• Mayumi KATO and Chia-Tien Dan Lo (itcc05)
• Department of Computer Science,
• University of Texas at San Antonio
• mayumik, danlo_at_cs.utsa.edu

Speaker Mayumi KATO
2
Outline

• Introduction
• Related work
• Proposed architecture
• Experiment and results
• Conclusion and future work

3
Introduction
Introduction
Mobile/Wireless Communication Client and server
models
Email service
Service Providers (network activated)
Service Archive
Web service
Service Management Component
Services Repository
Mobile commerce
Mobile Network
Audio, video animation
4
Main Issue of Java mobile/wireless computing
Introduction

• Many application demands more memory
• Mobile/wireless devices suffer from their small
  memory

5
Related work
Introduction

• Java classfile compression Pugh99
• (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
Fraser01 (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

6
The proposed architecture consists of
Java Virtual Machine (JVM) core
Memory management module
Cache unit
Delayed buffer
Decompressing unit
Local object accessed
(compressed form)
Delayed buffer is full?
Compressed heap
Address Lookaside buffer
ALB table
Compressing unit
accessed
stored
Store compressed block
7
The Proposed Architecture
Goals

• Reduce memory demands
• Allow large client applications to run on
  mobile/wireless embedded devices
• Minimize the number of active memory banks, and
  power off unused banks to eliminate the leakage
  current in memory system

8
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.
a group (a page)
during Java
objects
local and remote
execution

• Different from classfile Pugh,
• bytecode Clausen et al., Evans and Fraser

• Different from constant pool Rippen et al.
• native code zhang and Krintz

• Different from per-object Chen et al. 03

9
Assumptions
The Proposed Architecture

• Object is created either locally or remotely
• Objects that come over the Internet have been
  compressed at the sending side
• Objects that newly created inside the JVM are
  not compressed.

10
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
11
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
12
Java VM core
Memory management module
Cache unit
Decompressing unit
Delayed buffer
Compressed form
Delayed buffer is full?
Address Lookaside buffer
Compressed heap
ALB table
Compressing unit
accessed
stored
Store compressed block
13
Garbage collection
The Proposed Architecture

• 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

14
Garbage collection mechanism
The Proposed Architecture
From the caching unit
15
In-memory compression algorithms
The Proposed Architecture

• 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

16
WK algorithms

• Coding format lttaggt 4 bits 10 bits 22 bits

upper
Dictionary index
low
high
low
17
WK Example
Input

Dictionary
A0129FAE 1111 1010 1110
1
A0129CAE
1100 1010 1110
partial
2
A0129DAE
1101 1010 1110
A01290AE
3
A0129FAE
4
0000 1010 1110
no match
1111 1010 1110
exact
output
01 0100
18
Experiment and Results

• Examined compression techniques on
  mobile/wireless devices (CS LAN)
• Show their impact using space and time
  efficiencies

19
W gc watermark on the original architecture
(gc) W compgc watermark on the proposed
architecture (compression gc)
W gc spaceEfficiency
----------------- W compgc
T gc total execution time (including gc time)
on the original architecture T compgc total
execution time (including comp. and gc times) on
the proposed architecture
T gc timeEfficiency
---------------- T compgc
20
Summaries of Experiment Results
Experiment and results

• 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

21
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?

22
Conclusion and Future Work
Experiment and results

• 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.

23

• On-going work
• Tuning speed
• Future work
• Studying the impact of the compressed heap on
  remote object

24
Questions
URL paper ieee library 6 pages, but with Dr.
Los permission