220 likes | 306 Views
Interpreting Java Program Runtimes. Stuart Hansen UW - Parkside. The Problem:. The JVM influences program runtimes in complex and mysterious ways. The Real Problem:. It is VERY frustrating to obtain runtimes that you can’t explain. Algorithm Analysis.
E N D
Interpreting Java Program Runtimes Stuart Hansen UW - Parkside
The Problem: The JVM influences program runtimes in complex and mysterious ways The Real Problem: It is VERY frustrating to obtain runtimes that you can’t explain
Algorithm Analysis • One goal of algorithm analysis is to predict resources (e.g. time) that an implementation will require • There are many confounding influences • Speed of CPU - Implementation Language • Load on the system - Compiler • Size of physical memory • Operating system
Algorithm Analysis con’t. • We use the confounding influences as pedagogic tools • CPU time vs. elapsed time • Physical memory vs. virtual memory • Compiler optimizations
Java VM Presents New Issues • What are they? • Can we control them? • Can we use them at teaching aids?
Lack of Documentation • Lots of material on Java performance with lots of practical advice • None tells why my BubbleSort code doesn’t graph to be a parabola
Three Examples • Calls to Arrays.sort • Modified Mergesort • Rehashing All experiments performed using Sun’s Java SDK 1.4.2 under Debian Linux
Arrays.sort( ) • Compare runtimes of CS1 sorts to Arrays.sort()
Dynamic Class Loading • Java loads a class only when it is first referenced • Disk IO is slow • Can force pre-loading using Class.forName()
Side Issue – Java Startup • Simplest Java application public class Simple { public static void main (String [] args) { } } • Loads 280 classes
Mergesort • Requires an auxiliary array for merging • Should only be as big as subarrays to be merged • Too large of an array degrades performance to O(n2) • Let students work with and improve bad code
Finding the Parabola • Limit the graph to the smaller array sizes
Heap Management • Generational Garbage Collector • Major and minor garbage collections • Alternative is incremental garbage collection • Controlling Heap size • Grows as needed by default -Xms and –Xmx options
Things to Note • Still not perfectly smooth • Incremental GC creates a performance hit of about 10%
Rehashing • Suggested by Mike Clancy during panel discussion at SIGCSE 2002 • Create a Hashtable of a fixed size • Load with different amounts of data • Explicitly invoke rehash()
Optimizations in Java • Dynamic Compilation • Byte code to native code • Dynamic Optimization • E.g. Method inlining • Both are hard to control
Rehashing with Large Initial Heap • Lets more time be dedicated to rehashing
Remaining Issues • Each data set is still analyzed on an ad hoc basis • No consistent set of instructions to give to students to get meaningful runtimes • No handle on Java 5
Conclusion • Highly recommend experimentation in classes • Need tenacity to explain the results Questions?