Impact of Java Compressed Heap on Mobile/Wireless Communication

Transcription

1 Impact of Java Compressed Heap on Mobile/Wireless Communication Mayumi KATO and Chia-Tien Dan Lo Department of Computer Science University of Texas at San Antonio San Antonio, Texas fmayumik, Abstract M-commerce has shown up as e-commerce in mobile and wireless communication, and now deals with on-line banking, stock trading, auctions, transactions, and mobile media. M-commerce applications are implemented with, for example, Java technology that supports a client-and-server model and cross-platform mobile applications. They are attractive, but, need a large heap space, which may slow down the execution, lead to poor interactive response, and sometimes cause out of memory failure. We propose a Java computation mechanism with heap de/compression modules that reduce memory demand and allow client applications and embedded devices to take the advantage of compression techniques. Results show the impact in space and time efficiency of the proposed mechanism. The space efficiency is 1.8 to 2.5 and the speed is competitive with that of original Java technology. We believe that the proposed mechanism provides a good runtime environment for mobile/wireless computing Introduction Attractive wireless services have been launched into a third generation of wireless communication. Java technology is introduced to client and server models on mobile/wireless embedded systems. Clients are implemented using Java 2 Platform Micro Edition (J2ME) with Remote Method Invocation (RMI) package, and servers are made with Java 2 Platform Standard Edition (J2SE) or Java 2 Platform Enterprise Edition (J2EE). The Java technology is integrated into mobile/wireless devices, and is known for its advantage as follows: flexible user interfaces, robust security models, broad range 1 Partial support for this work is provided by the Center for Infrastructure Assurance and Security at UTSA through grants CIAS of built-in network protocols, and support for networked and stand-alone applications. Small handsets are now able to access , web service, mobile commerce, telephony, global position systems, and MP 3 Players, but suffer from their small memory. Current solutions for Java wireless computing are Just-in-Time (JIT), optimized interpreter, co-processor, Java core, and Jazelle technology. The JIT compilation is one of the software solutions and provides good speed. The optimized interpreter is another software solution and has lower memory overhead and simple debug. The co-processor is a hardware solution and offers reasonable speed. The Java core technology is another hardware solution and presents excellent performance. The Jazelle technology is a solution codesigned at hardware and software levels which achieves fast bytecode-execution, low power-consumption, low cost, and fast product integration. These solutions, however, have some shortcomings. The JIT suffers from the large memory overhead and start-up latency (power hungry, complex debug, and it must run in Random Access Memory (RAM)). The optimized interpreter has poor performance compared to C. The co-processor increases chip area, which leads to high power demand and system cost. The Java core technology encounters complex integration and poor performance with native code. The Jazelle technology consumes a large memory footprint. We have seen the problems of Java on mobile and wireless embedded devices and the advantages and disadvantages of the current solutions for Java wireless computing. We discovered a key factor, a small memory footprint for further accelerating the performance of the current and next generations of mobile/wireless computing. A small memory footprint will allow memoryhungry applications to run on a system with current available memory capacity in any of the existing solutions for Java technology. Techniques for a small memory footprint have been

2 studied in several areas: Java classfile compression [1], Java bytecode factorization [2], compact bytecode instructions [3][4], on-the-fly constant pool compaction [5], profile-driven code unloading [6], and Java heap compression [7][1][11]. We introduce a Java compressed heap model that de/compresses a group of objects, and show its impact on space, time and power efficiency. In the remaining paper, section 2 describes the related works, section 3 presents an overview of our proposed architecture, section 4 shows experiments and results, and section 5 presents our conclusion and future work. 2. Related work Pugh [1] addresses Java classfile compression that uses a wire-code format for collections of Java class files and a redesigned basic structure of information in a Java class file. Our proposed technique is different from Pugh s in that it is applied to the Java heap, and addresses Java objects. Clausen et al :[2], and Evans and Fraser [3][4] have studied Java bytecode compressions. Clausen et al : introduce factorization to reduce memory footprints. The factorization factorizes recurring instruction sequences into new instructions. This works as a compression unit that is roughly comparable to gzip. Evans and Fraser propose grammar-based compression for producing compact bytecode instructions, and interpreters for them. Our Java heap compression technique is different from Clausen et al : and Evans and Fraser in that our proposed architecture uses original bytecode formats and has de/compression modules that de/compress a page of objects and reduce runtime heap memory demand of each Java application. Ripper et al : [5] found that lots of constants in the constant pool are not accessed during execution and can be eliminated on the fly. On-the-fly constant pool compaction on Java In The Small (JITS) is proposed. Experiment results show that the constant pool could be reduced up to 7.78% which makes a method calling process fast. Our proposed technique for small memory footprints is different from Ripper et al : in that their studies used constant pool compaction; our studies use Java compressed heap. Zhang and Krintz [6] propose profile-driven code unloading for resource constrained Java Virtual Machines (VMs) to reduce memory footprints, and presents four strategies: online exhaustive profiling (OnX), online sample-based profiling (OnS), offline profiling (Off), and no profiling (NP). Results show around 5% reduction in code size with less than 1% of overhead. Our technique for small memory footprints is different from Zhang and Krintz in that they address Just-in-Time (JIT) and control native code loading, while we reduce memory footprints by in-heap compression techniques. Chen et al : [7] propose a set of memory management strategies for reducing memory footprints: markcompact-compress (MCC) collector, mark-compactlazy allocate (MCL), and mark-compact-compress-lazy allocate (MCCL). The memory management strategies use a zero removal compression scheme that compresses and decompresses a single object instance and array created by Java application. Memory could be saved 21% on average. Chen et al : show a feasibility of a runtime Java heap compression. Our Java heap de/compression technique is different from Chen et al : in that our computation mechanism has a virtual cache, and our de/compression is a page-based technique that de/compresses a page of local and remote objects and is invoked when a virtual cache miss occurs. 3. The proposed architecture We introduce a compression technique and propose a Java Virtual Machine (VM) with a compressed heap. The proposed architecture has two goals: one is to reduce on-the-fly heap memory demands for Java application programs if they are big, and tune them to run on mobile/wireless devices with small memory capacity; another goal is to minimize the number of active memory banks, and power off unused banks to eliminate leakage currents in memory systems. The proposed architecture is a client-and-server model, and has base architectures for both clients and servers. Client architectures use Java 2 Platform Micro Edition (J2ME) and its Remote Method Invocation (RMI) optional package. Server architectures are designed on Java 2 Platform Enterprise Edition (J2EE) or Java 2 Platform Standard Edition (J2SE). De/compression techniques are integrated into the Java Virtual Machines (VMs). The proposed architecture is designed to ensure minimum memory space and optimize power consumption. The proposed architecture consists of the Java Virtual Machines (VMs), a memory management module, a compressing unit, a decompressing unit, a caching unit, an Address Lookaside Buffer (ALB) table, and a compressed heap. The memory management module has a garbage collection mechanism and interfaces to the Java VM, the compressing unit, the caching unit, and the ALB table. The compressing unit includes a compressing buffer with interfaces to the compressed heap, the caching unit, and the ALB table. The decompressing unit consists of a decompressing buffer and in-

3 terfaces to the compressed heap, the caching unit, and the ALB table. The caching unit is composed of caching buffers (one works as a caching delayed buffer to accumulate objects (a page size)), and has interfaces to the memory management module, the compressing unit, and the decompressing unit. The ALB table holds page and mark bit information Operation examples of de/compression techniques De/compression techniques are used in combination with Java memory management systems. The memory management module calls de/compressing units upon object creation and object accesses as required. We will discuss how the compression technique is applied to Java computation mechanism. An object is created either locally or remotely. We assume that objects that come over the Internet have been compressed at a sending side and that objects newly created inside a Java Virtual Machine (VM) are not compressed. Figure 1 shows the proposed compression mechanism. The compression mechanism works in three ways: New local object created (uncompressed form) Caching unit Compressing unit Delayed buffer Delayed buffer is full? ALB Table Remote object created and accessed (compressed form) Decompressing unit Local object accessed ( compressed form ) Compressed heap Accessed Stored In the second cycle, the memory management module sends the object directly to the delayed buffer and updates the ALB table. In the same cycle, the compressing unit compresses the victim page. In the third cycle, the compressing unit stores the compressed page in the compressed heap and updates the ALB table. In all cases, the caching unit forwards the object to Java VM core when it is requested. Operations for remote objects are similar to the operations described above, except that a remote object is decompressed on the fly at the local decompressing unit and sent to the delayed buffer in the caching unit. The compression mechanism processes accessed objects in two ways. If an object requested is in the caching buffers, it is a cache hit and no compression is invoked. The object is simply forwarded to the Java VM core. If an object requested is not in any caching buffer, it is a cache miss and the memory management module reads the object over the Internet or from the local compressed heap. The remote object is read per object, while the local object is read per page. Operations for accessing the remote object are similar to operations for handling the remote object created. The local objects are accessed in the following manner. A page including a requested object is read from the compressed heap using the information in the ALB table and sent to the decompressing unit that decompresses the page. When the caching buffers are not full, the decompressing unit sends a decompressed page to the caching unit. When all the caching buffers are full, the caching unit selects one page as a victim and sends it to the compressing unit. In the second cycle, the decompressing unit sends the page to the caching unit. In the same cycle, the compressing unit compresses the victim page and stores it in the compressed heap. It also updates the ALB table. 1 Ox1 1 Ox1 1 Ox1 R Store compressed block 2 3 Ox122 Ox Ox Ox1726 R 4 Ox1726 Decompressing unit Page From delayed buffer in the caching unit Figure 1. Compression mechanism Case 1: when the delayed buffer is not full, the memory management module sends the object directly to it, while updating the Address Lookaside Buffer (ALB) table based on the move-to-front strategy. Case 2: when the delayed buffer is full and some of the caching buffers are not used yet, it is used as the delayed buffer. The memory management module sends the object to the delayed buffer and updates the ALB table. Case 3: when the delayed buffer and all the caching buffers are full, the caching unit sends the page in the delayed buffer as a victim to the compressing unit. GC buffer Compaction buffer P = {P } GC buffer Compaction buffer Compressing unit To delayed buffer in the caching unit P = {P } Page P Figure 2. Garbage collection mechanism 3.2. Garbage collection The Java memory management system has a Garbage Collection (GC) mechanism that consists of mark, sweep, and compaction phases. We redesigned

4 it to handle compressed objects. Our Garbage Collection (GC) mechanism includes de/compression modules and has a GC buffer and a compaction buffer. The mark phase is similar to the original GC mechanism except that mark bits are stored in an Address Lookaside Buffer (ALB) table. The sweep and compaction phases are migrated into de/compression modules and delayed until an object is accessed and/or a cache miss occurs. Figure 2 shows how the proposed garbage collector works. Given objects 1, 2, 3, and 4 that are stored in page, page is checked if it contains garbage objects by traversing trees. Objects 1 and 4 are marked as live objects and objects 2 and 3 are determined as garbage objects. For example, when object 4 is accessed and a cache miss occurs, the sweep and compaction phases are called twice: one for page ; and another for a victim page. Page : compressed page is loaded to the decompressing unit. The decompressing unit decompresses page and sends it to the GC buffer. The sweep phase of the garbage collector is invoked to the GC buffer and collects garbage objects using mark information in the ALB table. The live objects are sent to the compaction buffer, and forwarded to the delayed buffer after relocation and compaction. Victim page : the caching unit selects a victim page, and forwards it to the GC buffer. The sweep phase is invoked to the victim page. The live objects are sent to the compaction buffer and forwarded to the compressing unit. The compressing unit compresses the live objects and stores them in the compressed heap In-memory compression algorithms Popular compression algorithm Lempel-Ziv (LZ) family is designed for human text and is not suitable for data in memory/cache because of its regularity modeling. Most in-memory/cache data is word-aligned integers and pointers and contains many repeating zero values. The majority of its information is found in its low bits. The Wilson-Kaplan (WK) compression family [8][9] was designed to capture these characteristics, and we use it in the proposed architecture. In the remaining section, we briefly discuss the WK family. The WK algorithms are a dictionary-based approach that compares input symbols to recently seen symbols in a dictionary and models the similarity of values that are spatially local. A coding format is illustrated below. <tag>[4 bits dictionary index][1 low bits][22 upper bits] The compressing operation has two phases: 1. packing phase : the majority of information is contained in low bits of input words, which are compacted as short as possible by extracting and combining only their information parts. For example, if information is stored in the lower eight bits, each lower eight bits of four words can be combined into a new single word by a set of shift and bitwise XOR operation. 2. compression phase : each packed word is compared to some expected values (Figure 3), and all information (tag and other bits) are assembled into a compressed form. Coding varies on match types (Table 1). Input word If an input word is zero, encode it as ZERO, Otherwise, compare the upper 22 bits of the input word to the upper 22 bits of the zeroth element in the dictionary. Zeroth Element in Dictionary If they have the same pattern, compare their full bits (case 1), Otherwise, compare the upper 22 bits of the input word to the first element in the dictionary (case 2). Case 1: Case 2: If they have the same pattern, encode it as EXACT match. Otherwise, mark it as PARTIAL match and further compare it to the first element in the dictionary (case 2). First Element in Dictionary Repeat the above operation with the remaining elements in the dictionary. 4 way set Associative Dictionary 4 way set Associative Dictionary If the upper 22 bits of the input word did not match any of the upper 22 bits of the four elements in the dictionary, encode the input word as NO match. Otherwise, encode the input word as PARTIAL match. Figure 3. Compression example Match type ZERO Table 1. Coding Coding specification <x> EXACT <x1><4bitsdictionary index > PARTIAL <x2><4 bits dictionary index ><1low bits > MISS <x3>< 32 bits literal pattern > The basic decompressing operation is to extract a tag from the compressed input and decompress the data using the tag information and the coding specification (Table 1) Page replacement policy Least-recently-used (LRU) page replacement policy is used in the proposed architecture. Any of existing page replacement policies could be integrated.

5 3.5. Key features Key features of the proposed architecture are integration of compression techniques to Java Virtual Machines (VMs), Java compressed heap mechanisms, Java remote object compression mechanisms, garbage collection mechanisms for the compressed Java heap, small memory demand, low power consumptions, and small network bandwidths. 4. Experiment and results We will examine compression techniques on wireless devices and show their impact in space and time efficiency. The space efficiency is defined as spaceefficiency = Wgc Wcomp+gc where Wgc is the watermark on the original architecture with gc and Wcomp+gc is the watermark on the proposed architecture with compression + gc. The time efficiency is defined as timeefficiency = Tgc Tcomp+gc where Tgc is the execution time on the original architecture with gc, and Tcomp+gc is the execution time on the proposed architecture with compression + gc. Tcomp+gc is calculated by (1) (2) Tcomp+gc = Costgc + Costde=comp (3) The cost of garbage collection (Costgc) isdefined as the total execution time for mark phases. The cost of sweep and compact phases are migrated into de/compression costs. The cost of garbage collection is accumulated during the program execution. The cost of de/compression (Cost de=comp )isproportional to the number of cache misses and classified into two cases: when the cache is full, one compression and one decompression are invoked (case 1); when the cache is not full, one decompression is invoked (case 2). The de/compression time is accumulated during the execution, and its total cost is calculated by Costde=comp = X Costcase1 + X Costcase2 (4) The compressed heap is simulated on Solaris 9 with SunOS 5.9: Each object is traced when it is created and accessed. The simulation measures the number of Garbage Collection (GC), the execution time of GC, the number of cache misses (that are related to the number of compressions and decompressions), and the execution time of In-heap de/compression. The space and Table 2. Benchmarks MIDlet Suite Viewer Description wireless service program for Java-enabled 256KB heap (J2ME) mobile devices ( ). demos(http) technical demonstration program of h ttp 64KB heap for MIDP ( comes with Sun Java KVM 2 ). Stock Get stock quotes from a publicly a vailable website, 64KB heap and set alerts ( comes with Sun Ja va KVM). Audiodemo Listen to sounds using Mobile Media APIs audio 64KB heap building block ( comes with Sun Ja va KVM ). manyballs game program (comes with Sun Java KVM). 32KB heap Configuration Base architecture Heap size Page size Cache size Compression algorithm Options Table 3. Base configuration Description Clien t: Java 2 Platform, Micro Edition (J2ME) Remote Method Invocation (RMI) optional pac kage Server : Java 2 Platform, En terprise Edition (J2EE) Java 2 Platform, Standard Edition (J2SE) 32KB, 64KB, 128KB, or 5,, bytes (maximum) 4KB as default (-4KB) 64KB as default (-64KB) Wilson-Kaplan (WK) family : WK 4 4 Any of existing compression algorithms, ho wever, works in the proposed architecture, for example, jar, par, gzip, zip, x-match, zero-removal, and compress. GC mode on, compaction mode on, fastbytecode mode off time efficiencies are calculated using formulas (1) to (4). We use wireless Java applications as benchmarks. Table 2 shows a list of benchmarks and brief descriptions. We design experiments to evaluate the proposed architecture. Table 3 shows a base configuration of the proposed architecture. We use Java 2 platform, Micro Edition (J2ME) and its RMI optional package for clients, and Java 2 platform, Enterprise Edition (J2EE) and/or Java 2 platform, Standard Edition (J2SE) for servers. The maximum heap size is 5,, bytes, but is tuned for each application program. For example, Viewer uses 256KB as a heap size. The default page size is 4KB, and the default cache size is 64KB. The number of the cache entry is 16. We use the Wilson- Kaplan WK 4 4 algorithm for In-heap compression. The options of J2ME are garbage collection and compaction modes. Table 4 shows the summaries of experiment results. Table 4. Space and time efficiency Application Space Time efficiency efficiency Viewer HTTP demo Stock Audiodemo manyballs [Space efficiency] Four out of five benchmark applications exceed space efficiency of 2., which indicates In-heap compression technique can reduce the heap memory demand to 5 % or more on average. Experiment results show that the space efficiency is independent of the size of the Java dynamic heap (256KB in Viewer, 64KB in HTTP Demo, Stock and Au-

6 diodemo, and 32KB in manyballs). The space efficiency of 2. also indicates half of the memory banks for the Java heap may never be turned on in the memory bank system. More than 5 % of the memory leakage can be saved. [Time efficiency] HTTPdemo, Audiodemo, and manyballs reach time efficiency of 1., which means the sum of the modified garbage collection time and the total de/compression time is almost equal to the original garbage collection time and occupied a small part of the total execution time. HTTPdemo and audiodemo are client programs that download http text and audio files, and manyballs is a stand-alone game program. Their program characteristics are different from each other, but there was no difference in time efficiency between them. Good data and code locality and less invocation of garbage collector (including de/compression) contribute to the time efficiency of 1.. Stock and - Viewer have the time efficiency of.99. They performed worst in speed, but time overhead is within 1 %. Stock and Viewer are client programs but have richer functionality than HTTPdemo and Audiodemo: Stock and Viewer use local databases, and have disk accesses. The use of local databases may affect the performance of the compressed heap proposed. We are further examining key factors for poor performance. 5. Conclusion and future work We have seen the impact of Java compressed heap on wireless communication. Results show that the compressed heap is effective to ensure small memory footprints for wireless applications with any memory demand. Tuning speed is a critical issue in our on-going research, and the impact of the compressed heap on remote objects is one of our future works. Acknowledgment The authors would like to thank anonymous reviewers for their comments and suggestions and Ms. Ball for her proof-reading. This researc h is supported by the Center for Infrastructure Assurance and Security and doctoral fellowships under the department of computer science, the university of Texas at San Antonio. References [1] W. Pugh, Compressing Java class files, In Proc.of the ACM SIGPLAN 1999 Conferenc e on Programming language design and implementation PLDI'99, A CMPress, NY, USA, May 1999, pp [2] L. Clausen, U. Schultz, C. Consel, and G. Muller, Java bytecodes compression for low-end embedded systems, ACM transactions on programming languages and systems, 22:3, A CM Press, NY, USA, May 2, pp [3] W. Ev ans and C. Fraser, Bytecode compression via profiled grammar rewriting, In Pr oc. of the ACM SIGPLAN 21 conference on Pr o- gramming language design and implementation PLDI'1, A CMPress, NY, USA, May 21, pp [4] W. Evans and C. F raser, Grammar-based compression of interpreted code, Communications of the ACM, 46:8, A CM Press, NY, USA, August 23, pp [5] C. Rippert, A. Courbot, and G. Grimaud, A lowfootprin tclass loading mechanism for embedded Java virtual machine, In Proc. of the 3rd Int'l Conference on Principles and Practice ofprogramming in Java PPPJ'4, the ACM Int'l Conference Proc. series, Computer Science Press, Trinity College Dublin, Ireland, June 24, pp [6] L. Zhang and C. Krintz, Profile-driven Code Unloading for Resource Constrained JVMs, In Pr oc. of the 3rd Int'l Conference on Principles and Practice ofprogramming in Java PPPJ'4, theacm Int'l Conference Proc. series, Computer Science Press, Trinity College Dublin, Ireland, June 24, pp [7] G. Chen, M. Kandemir, N. Vijaykrishnan, M. Irwin, and B. Mathiske, Heap Compression for Memory-Constrained Java Environments, In Proc. of the 18th annual ACM SIGPLAN conference onobject-oriented programming, systems, languages, and applications OOPSLA'3, ACM Press, NY, USA, October 23, pp [8] P. Wilson, S. Kaplan, and Y. Smaragdakis, The case for compressed caching invirtual memorysystems, In Proc. of the USENIX Annual Technical Conference, USENIX Association, Berkeley, CA, June 1999, pp [9] S. Kaplan, Compressed caching and modern virtual memory systems, PhD. Thesis, The University oftexas at Austin, TX, USA, December [1] M. Kato and C. Lo, A heap de/compression module for wireless Java, In Proc. of the 3rd Int'l Conference on Principles and Practice ofprogramming in Java PPPJ'4, the ACM Int'l Conference Proc. series, Computer Science Press, Trinity College Dublin, Ireland, June 24, pp [11] C. Lo and M. Kato, Pow er Consumption Reduction in Java Embedded Systems, In Pr oc. of Int'l Conference on Computer, Communication and Control Technologies CCCT'3 and the 9th Int'l Conference on Information Systems Analysis and Synthesis ISAS'3, volume 1, IIIS, Orlando, Florida, USA, July-August 23, pp