230 likes | 369 Views
Program Reduction Focusing on Compaction. Benjamin J. Fruchter MS CS Candidate March 12 2004. Program Reduction. Any method or combination of methods that modify code to allow a program to be stored and run with less resources. Program Reduction Overview.
E N D
Program ReductionFocusing on Compaction Benjamin J. Fruchter MS CS Candidate March 12 2004
Program Reduction • Any method or combination of methods that modify code to allow a program to be stored and run with less resources
Program Reduction Overview • Consumer driven push for smaller, faster, more powerful electronic devices • Same functionality, fewer resources, more constraints • Hardware advancing, but not enough to keep up with demand • Need a way to fit full sized programs onto much smaller platforms
Constraints • Three major constraints • Space • Storage (ROM) • Runtime (RAM) • Time • Input reaction • General runtime • Energy • Batteries getting better but not fast enough
Reduce, Reuse, Recycle • Various methods of reduction • Reduce functionality • Compress the code • Compact the code
Reduce Functionality +/- • Quick • Takes very little time • Decide what is not needed and throw it out • No new development needed • Dirty • Loss of functionality only occasionally acceptable • Wasteful: getting rid of functionality that took time to develop and test
Code Compression • Compressed code takes up less space without losing functionality • Similar to data compression • Uses smaller symbols to represent string of input • Use of language and grammar structure to create interpretable compressed program • Stored on ROM then decompressed at run time to avoid negating storage benefits • Many different techniques available some including hardware modifications
Code Compression +\- • Effective storage space saving • Thorough algorithms combined with advanced hardware make effective solutions • Though space required is decreased often time and energy consumption increase • Work to decompress the stored code at run time requires costly computations resulting in decreased time and energy efficiency • Storage space decreased but often RAM space requirements increase
Code Compaction • Irreversible modification to program code that reduces code size without losing functionality • Combination of various methodologies • Traditional compiler optimizations • Removing unused / useless code • Removing debugging information • Undoing programming standards set in place to increase readability or ease versioning
Code Compaction +/- • More resource efficient in runtime memory, time and energy consumption • No functionality loss • Time performance often increases instead of decreased • Not as effective at saving storage space as compression • Many cases where certain methods can not be used
Code Compaction • Warranted by object-oriented programming standards • Reduction of logical organization and readability to gain space • Consider: Java Applet Hello World • How many hundreds of lines of code are included? • How many of those included classes, methods, and fields are actually used?
Application Extractors • Java Application Extractor (JAX) • Developed at IBM for use with J2ME • Very effective method of pulling out the functional pieces of a Java program • On average resulting in 40% smaller JAR executable • Particularly effective when a program includes libraries developed by third parties
Jax • Process • Determine all entry points (by class) • Find all reachable / referenced classes • Create call graph to find unreachable methods • Jax allows you to choose which algorithm to use to construct the call graph (RTA, XTA most common) • Removes redundant fields • Unreachable or write only • Class hierarchy transformation • Name compression
Jax – Unreachable / Useless • Classes • Not directly or indirectly referenced by the ‘entry point’ class or classes • Not a super class of a referenced class • Methods • Discovered via a call graph • Fields • Contained by unreferenced methods • Only written to, hence value does not effect outcome of program, so useless
Jax – Call Graphs • Basic Theory • Play it safe and don’t remove unless sure • More complex than name resolution due to polymorphism • RTA – Rapid Type Analysis • Most common due to high speed and acceptable accuracy • XTA – Exact Type Analysis • More stringent but rarely worth the time decrease from RTA
Jax • Class Hierarchy Transformations • Combining of adjacent (sibling) classes • When run time object size not increased • When program behavior not affected • Reduces number of class files each of which contain their own pool of literals and constants • Name Compression • All references in Java made through string literals • Reducing name length of classes, methods, fields all beneficial • Sacrifice readability for the space saving benefit
Jax – Benchmark • Compaction of Hyper/J with Jax • Breakdown of space conservation Percent of Original Step Size Remaining Unreferenced classes 86% Redundant attributes 67.1% Unreachable methods 47.6% Dead fields 42.6% Class hierarchy compaction 35.2% Name compression 27.8% Run under 4 minutes on a 800MHz Intel based machine with 512MB of memory
RISC Code Compaction • ARM Infrastructure • Two instruction sets available • ARM – 32 bit • Thumb – 16 bit • ARM – fast but takes up a lot of memory • Thumb – space efficient but slow • As always we want the best of both worlds
Mixed Width Instruction Sets • Processor able to handle both sets of instructions • Able to switch back and forth between the two during program execution • Each set performs better under different circumstances • Those conditions can be programmatically identified using a heuristic to make the decision of whether to switch or not
Mixed Width Instruction Sets • Switching done at a procedure level • All ARM code is first converted to Thumb code • The Thumb code is chosen if either • The instruction count is lower than the ARM code • The instruction count is higher by a factor of T1% but the overall size of the code is smaller by a factor of T2% • On average mixed code is nearly as small as Thumb code and runs nearly as fast as ARM • Stressing of low instruction count saves energy
Mixed Width Instruction Sets • Switching between instruction sets more often would negate benefits due to high overhead • Other solutions include • Instruction coalescing (AXThumb) • Application specific code compression (ThumbScrews)
Code Reduction • Many methods available • Few clear ‘best’ choices • Trade offs are usually involved • Classic space for time outside of compaction • Compaction options most attractive due to lack of performance hits