1 / 22

Interpreting Java Program Runtimes

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.

kenneth-garza
Télécharger la présentation

Interpreting Java Program Runtimes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Interpreting Java Program Runtimes Stuart Hansen UW - Parkside

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

  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 1.4.2 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 • 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 • 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 • Highly recommend experimentation in classes • Need tenacity to explain the results Questions?

More Related