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