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

2. Outline 1.Introduction 2.Related work 3.Proposed architecture 4.Experiment and results 5.Conclusion and future work

3. Mobile Network Service Providers (network activated) Service Management Component Services Repository Service Archive Email service Web service Mobile commerce Audio, video animation Mobile/Wireless Communication Client and server models Introduction

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 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)

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

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

8. 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) execution during 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

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

10. stored Compressed heap Decompressing unit Compressing unit ALB table Cache unit Delayed buffer New local object created (uncompressed form) Java VM core Memory management module Store compressed block Delayed buffer is full?

11. stored Compressed heap Decompressing unit Compressing unit ALB table Cache unit Delayed buffer Remote object created and accessed (compressed form) Java VM core Memory management module Delayed buffer is full? Store compressed block Address Lookaside buffer

12. stored accessed Compressed heap Decompressing unit Compressing unit ALB table Cache unit Delayed buffer Java VM core Memory management module Delayed buffer is full? Store compressed block Compressed form Address Lookaside buffer

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

14. Garbage collection mechanism The Proposed Architecture From the caching unit

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

16. WK algorithms Coding format [4 bits] [10 bits] [22 bits] Dictionary indexlow upper Match type Coding specification ZERO EXACT PARTIAL MISS high low

17. WK Example A0129FAE 1111 1010 1110 A0129CAE A0129DAE A01290AE A0129FAE 0000 1010 1110 1111 1010 1110 1101 1010 1110 1100 1010 1110 no match partial exact Input Dictionary 1 2 4 3 output01 0100

18. Experiment and Results 1.Examined compression techniques on mobile/wireless devices (CS LAN) 2.Show their impact using space and time efficiencies

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

20. Summaries of Experiment Results Application Space Efficiency EmailViewer 256KB heap 2.05 HTTP demo 64KB heap 1.80 Stock 64KB heap 2.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

21. 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 heap 0.99 HTTP demo 64KB heap 1.00 Stock 64KB heap 0.99 Audiodemo 64KB heap 1.00 Manyballs 32KB heap 1.00

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

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. Lo’s permission