Impact of Java Compressed Heap on MobileWireless Communication

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 Mobile/Wireless Communication Service Providers (network activated) Client and server models Email service Service Archive Web service Mobile Network Service Management Component 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 2. [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 is full? Address Lookaside buffer Compressing unit Decompressing unit Local object accessed (compressed form) Compressed heap ALB table accessed Store compressed block stored

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 ü Different classfile [Pugh] , [Rippen Different from per-object constant 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 Delayed buffer is full? Address Lookaside buffer Compressed form 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 < 0 x 0 > < 0 x 1 >< 4 bits dictionary index > PARTIAL < 0 x 2 >< 4 bits dictionary index >< 10 low bits> low MISS < 0 x 3 > < 32 bits literal pattern >

WK Example Input A 0129 FAE 1111 1010 1110 partial 1100 1010 1101 1010 1110 no match 0000 1010 1110 exact 1111 1010 1110 Dictionary 1 2 3 4 output A 0129 CAE A 0129 DAE A 01290 AE A 0129 FAE 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 space. Efficiency = --------- W comp+gc : watermark on W comp+gc the proposed architecture (compression + gc) time. Efficiency T gc : total execution time (including gc time) on the T gc = -------- original architecture T comp+gc : total execution time (including comp. and gc times) on the proposed architecture

Experiment and results Summaries of Experiment Results Application Email. Viewer 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 2. 50 – Half of the memory banks for Java heap may never be turned on 256 KB heap HTTP demo 64 KB heap Stock 64 KB heap Audiodemo 2. 20 64 KB heap Manyballs 32 KB heap 2. 09 – More than 50% of the memory leakage can be saved

Experiment and results Application Email. Viewer time Efficiency 0. 99 256 KB heap HTTP demo No time overhead 1. 00 64 KB heap Stock 0. 99 64 KB heap Audiodemo 1. 00 64 KB heap Manyballs 32 KB heap • 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 Email. Viewer 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