The design, implementation, and evaluation of adaptive code unloading for resource-constrained devices

Abstract

Java Virtual Machines (JVMs) for resource-constrained devices, e.g., hand-helds and cell phones, commonly employ interpretation for program translation. However, compilers are able to produce significantly better code quality, and hence, use device resources more efficiently than interpreters, since compilers can consider large sections of code concurrently and exploit optimization opportunities. Moreover, compilation-based systems store code for reuse by future invocations obviating the redundant computation required for re-interpretation of repeatedly executed code.However, code storage required for compilation can increase the memory footprint of the VM significantly. As a result, for devices with limited memory resources, this additional code storage may preclude some programs from executing, significantly increase memory management overhead, and substantially reduce the amount of memory available for use by the application.To address the limitations of native code storage, we present the design, implementation, and empirical evaluation of a compiled-code management system that can be integrated into any compilation-based JVM. The system unloads compiled code to reduce the memory footprint of the VM. It does so by dynamically identifying and unloading dead or infrequently used code; if the code is later reused, it is recompiled by the system. As such, our system adaptively trades off memory footprint and its associated memory management costs, with recompilation overhead. Our empirical evaluation shows that our code management system significantly reduces the memory requirements of a compile-only JVM, while maintaining the performance benefits enabled by compilation.We investigate a number of implementation alternatives that use dynamic program behavior and system resource availability to determine when to unload as well as what code to unload. From our empirical evaluation of these alternatives, we identify a set of strategies that enable significant reductions in the memory overhead required for application code. Our system reduces code size by 36%-62% on average which translates into significant execution time benefits for the benchmarks and JVM configurations that we studied.

Managing bounded code caches in dynamic binary optimization systems

“…Recent work has investigated the problem of caching small portions of Java programs on resource-constrained devices [Chen et al 2003;Zhang and Krintz 2005;Zhou et al 2005]. This problem is similar to code cache management because of the high overhead of replacing code on remote devices; however, it differs in that the unit of eviction is a fixed-size region.…”

JDiet: Footprint Reduction for Memory-constrained Systems

“…While virtual machine alteration is a valid and commonly used technique in academia [Blackburn et al, 2006;Bond and McKinley, 2008;Jump and McKinley, 2007;Tang et al, 2008;Zhang and Krintz, 2005], particularly the use of the Jikes Research Virtual Machine [Jike RVM Project, 2009], doing so would hinder the applicability to the various operational environments it aims to support. Virtual machine modification and bytecode engineering both provide transparency and type orthogonality, but virtual machine modification lacks extensibility and configurability; unless aimed at a specific software product, a virtual machine with custom memory management is unlikely to support customization or configuration.…”

“…Examples of memory-constrained systems include expert systems [Marney and Ibrahim, 1995], scientific computing , data mining [Kantardzic, 2002;Liu, 2008], business applications, and sensor networks [Liu et al, 2005]. Because of its safety and portability, Java is commonly utilized to implement software on resource-constrained devices [Bhadra et al, 2009;Zhang and Krintz, 2005]. For example, the K virtual machine (KVM) [Sun Microsystem, Inc., 2000] is engineered for running Java applications in embedded systems with less than 128 KB of main memory.…”