A Heap DeCompression Module for Wireless Java

1
A Heap De/Compression Module for Wireless Java

• Mayumi KATO, Chia-Tien Dan Lo
• The University of Texas
• at San Antonio

Speaker Mayumi KATO
2
Road Map

• Introduction
• Overview
• Proposed Architecture
• Memory Management
• Simulation and Results
• Simulations 1 - 4
• Conclusion and Future Work

3
Introduction

• Java technology
• Java 2 platform, Micro edition J2ME
• Wireless Java
• Problems
• Solutions?

4
Java technology (J2SE)
Java technology Micro edition(J2ME)

• Developed for thin client computing
• Write-one-run-anywhere model
• Integrated into portable devices

• A platform for consumer and embedded devices
• A subset of standard Java API
• Delivers the power and benefits of standard Java
  technology

• Portable devices
• mobile/wireless embedded systems
• needs smaller JVM

5
Wireless Java

• Multi-functional
• cellular phone, PDAs
• Sophisticated Java applications
• have been developed for wireless Java, but
• Require a large volume of data

• Problems
• Slow execution
• Leads poor user experience
• Runs out of memory in the worst case

6
Solutions

• One Solution
• Integrate memory having a large capacity
• Higher cost and power consumption
• Alternative Solution
• Reduce memory space required for executing
  application
• Compression technique is one candidate for
  achieving the solution

Time overhead
7
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.
(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 heap memory compression
• Lo and KATO
  03, Chen et al. 03

8
What is proposed?

• A computation mechanism with de/compression
  module
• Goal
• Reduce Java heap memory demand with compression
  techniques
• Expected Effect
• Allow a large program to run on current available
  memory capacities

9
The proposed architecture consists of
Network/Disk
Java Kilobyte Virtual Machine (KVM)
Compressing Unit
Delayed Buffer
Object Creation
Object Access
Compressing Buffer
Memory Management Module
Address Lookaside Buffer (ALB) Table
Compressed Heap
Cache
Decompressing Unit
Decompressing Buffer
10
Operation Example 1
Compression timing
Network/Disk
Java Kilobyte Virtual Machine (KVM)
Compressing Unit
Delayed Buffer
Object Creation
Object Access
Compressing Buffer
Memory Management Module
Address Lookaside Buffer (ALB) Table
Compressed Heap
Cache
Decompressing Unit
Decompressing Buffer
11
Operation Example 2
Compression timing
Network/Disk
Java Kilobyte Virtual Machine (KVM)
Compressing Unit
Delayed Buffer
Object Creation
Object Access
Compressing Buffer
Memory Management Module
Address Lookaside Buffer (ALB) Table
Compressed Heap
Cache
Decompressing Unit
Decompressing Buffer
12
Operation Example 3
Network/Disk
Java Kilobyte Virtual Machine (KVM)
Compressing Unit
Delayed Buffer
Object Creation
Object Access
Compressing Buffer
Memory Management Module
Address Lookaside Buffer (ALB) Table
Compressed Heap
Cache
Decompression timing
Decompressing Unit
Decompressing Buffer
13
Memory Management

• Memory Allocation/Relocation
• Page Replacement Policy
• Garbage Collection
• Shared VM

14
Heap memory reallocation algorithm
New compressed page is
1. Greater than the old page
reallocted
11111
00000
change the bitmap to reflect releasing free
memory block
2. Equal to the old page
stored in the same address as the old one
3. Smaller than the old page
stored in the same address as the old one
11111
00000
change the bitmap to reflect releasing free
memory block
15
How we know which page a requested
object in?

• ObjectID page bits offset bits

Unsigned long type
page no.
Start address in page
(32 bits)
(x bits)
(y bits)
Reserved for user defined optimization
16
How we extract the requested object
from the page loaded?
Object header
Object size
24 bits
17
Page Replacement Policy

• LRU (Least Recently Used)
• A popular paging system
• Selects a page less recently used as a victim
  page

18
Page Replacement Policy Modified

• Modified LRU (Modified Least Recently Used)
• A combination of two strategies
• LRU Accessing an object
• FIFO Creating an object

Cache
LRU pointer
C
C
C
Cache entry
E1, E5
E4, E8
C
Counter
FIFO pointer
E3, E7
E2, E6
timestamp
C
C
19
Garbage Collection or Compression
Configuration 1
Original configuration

• Configuration
• de/compression,
• no garbage collection

With GC
Without GC
Garbage collection
Compression
Compaction
20
Non-Shared VM Shared VM
VM

• Emulator
• Instancing
• Application
• Emulator
• Re-Instancing

• Emulator
• Instancing
• Application
• Emulator
• Re-Instancing

VM
VM
Process
VM
21
Simulations and Results

• Simulation Design
• Simulation 1
• Compare page replacement policy
• Simulation 2
• Measure
• compression ratio and time
• Simulation 3
• Measure the watermark, and the number of GC
• and GC time
• Calculate speed up and space efficiency using
• simulations 1, 2, and 3
• Simulation 4
• Show the impact of shared VM

22
Simulation Design

• J2ME, KVM
• Heap size 500KB
• Page size 4KB
• Cache size 16KB
• Cache block 4KB
• Multi-bank Organization
• Compression algorithm Wilson-Kaplan-4 X 4,
• (any existing algorithm)
• Solaris 9, SunOS 5.9

Speed up T gc - T nongc,comp Space
Efficiency Wgc / W nongc,comp
23
Simulation 1 Cache Miss
Compare replacement policies
24
Simulation 2 Compression
Measured compression ratio and
de/compression time
48.54
346,064
210,425
25
Simulation 3 watermark
memory demand (bytes)
Watermark for configuration without gc
memory allocation for interactive screen
Watermark for Configuration with gc
Watermark for original configuration
(application only)
Watermark for configuration without gc
26
Simulation 3
Space Efficiency
(bytes)
27
Simulation 3 GC impact
Speed up
28
Simulation 4 Shared VM
(cache misses)
impact of shared VM
29
Conclusion and Future Work

• Proposed a computation mechanism with Java heap
  de/compression module
• De/compression is
• Faster than garbage collection, and
• Competitive in memory saving to garbage
  collection
• (Simpler in implementation than garbage
  collection)
• Factors affect performance
• Page replacement policy
• Shared VM

30
Ongoing and Future Work

• Configuration with GC and shared VM scheme is
  under experiments
• Formalizing Energy Analysis for Java
• Introducing Reconfigurable Computing

31

• Questions