1. Interpreting Java Program Runtimes
Stuart Hansen
UW - Parkside

2. The Problem: The Real 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

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

4. Algorithm Analysis con’t.
We use the confounding influences as pedagogic tools
CPU time vs. elapsed time
Physical memory vs. virtual memory
Compiler optimizations

5. Java VM Presents New Issues
What are they?
Can we control them?
Can we use them at teaching aids?

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

7. Three Examples Calls to Arrays.sort Modified Mergesort Rehashing
All experiments performed using Sun’s Java SDK under Debian Linux

8. Arrays.sort( )
Compare runtimes of CS1 sorts to Arrays.sort()

9. Dynamic Class Loading
Java loads a class only when it is first referenced
Disk IO is slow
Can force pre-loading using Class.forName()

10. Side Issue – Java Startup
Simplest Java application
public class Simple {
public static void main (String [] args)
{ } }
Loads 280 classes

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

12. Results

13. Finding the Parabola
Limit the graph to the smaller array sizes

14. Heap Management Generational Garbage Collector Controlling Heap size
Major and minor garbage collections
Alternative is incremental garbage collection
Controlling Heap size
Grows as needed by default
-Xms and –Xmx options

15. Incremental GC

16. Things to Note Still not perfectly smooth
Incremental GC creates a performance hit of about 10%

17. 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()

18. Rehashing Results

19. Optimizations in Java Dynamic Compilation Dynamic Optimization
Byte code to native code
Dynamic Optimization
E.g. Method inlining
Both are hard to control

20. Rehashing with Large Initial Heap
Lets more time be dedicated to rehashing

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

22. Conclusion Questions? Highly recommend experimentation in classes
Need tenacity to explain the results
Questions?