Impact of Java Compressed Heap on Mobile/Wireless Communication

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 • Introduction • Related work • Proposed architecture • Experiment and results • Conclusion and future work

3. Introduction Introduction Mobile/Wireless CommunicationClient 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. Introduction Main Issue of Java mobile/wireless computing • Many application demands more memory • Mobile/wireless devices suffer from their small memory

5. Introduction Related work Java classfile compression[Pugh’99] (small file, but the same info. as of a Jar file: eliminate redundancy) 6. Java heap memory compression [Lo and KATO ’03], [Chen et al. ’03], [KATO and Lo ’04] 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. 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) local and remote objects during Java 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. The Proposed Architecture Assumptions • 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 Delayed buffer Decompressing unit Compressed form Delayed buffer is full? Address Lookaside buffer Compressed heap ALB table Compressing unit accessed stored Store compressed block

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

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

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

16. WK algorithms Coding format<tag> [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 3 A01290AE 4 A0129FAE no match 0000 1010 1110 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 comp+gc : watermark on the proposed architecture (compression + gc) W gc spaceEfficiency = ----------------- W comp+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 T gc timeEfficiency = ---------------- T comp+gc

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