Java Troubleshooting and Performance Margus Pala Java Fundamentals 08.12.2014
Agenda Debugger Thread dumps Memory dumps Crash dumps Tools/profilers
Rules of (performance) optimization 1. Don't optimize 2. Don't optimize yet (For experts only) Hardware is Cheap, Programmers are Expensive --Unknown --Jeff Atwood
Types of performance bottlenecks Low memory GC performance Lot of GC flags to tune Thread contention Ineffective algorithm Unoptimized big collection operation Too many objects created and dropped
Low tech tips Print statuses Activity and variable values Visited methods To System.out, System.err or log Throw and print exceptions Measure time System.currentTimeMillis() Break it down to single statement
Rules of (performance) optimization 1. Don't optimize 2. Don't optimize yet (For experts only) Hardware is Cheap, Programmers are Expensive --Unknown --Jeff Atwood
Common GC tuning flags and strategies Initial vs max sizes of memory areas -Xms512m Xmx512m (avoids JVM own optimizations) Relative sizes of old and new areas (short or long living obj) -XX:NewRatio=8 -XX:NewSize=512m -XX:MaxNewSize=512m Collector type -XX:+UseParallelOldGC (high throughput) -XX:+UseConcMarkSweepGC (low latency) -XX:+UseG1GC (predictable low latency)
Debugging Basics Set breakpoints Run in debug mode Controlling execution Step into Step over Step out Resume Suspend Stop
Breakpoints view Allows to control breakpoints in one place Enable/Disable Delete Delete all Skip all Setup conditional breakpoints
Variables view Shows list of variables and their values Can edit variable values Use View Menu up right to config Show constants Show static values view menu layout columns Enables to choose different data to be shown Detail formatter Choose class method to return more clear representation
Advanced debugging Conditional breakpoint Based on hit count Based on coded condition Suspend when true Suspend when condition value changes Watchpoint Read or write the field On Instance or static non-final variable
Other breakpoints Exception breakpoint Added from breakpoints view Suspend on caught exceptions Suspend on uncaught exceptions Method breakpoint Added from left margin of method header Suspend on method entry Suspend on method exit Load class breakpoints Added from outline, rightclick on class
Step Filter Allows skipping framework classes while stepping into Window Preferences Java Debug Step filtering
Remote debugging Allows to debug JVM on another machine Needs JVM arguments: -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspe nd=y,address=5005 Needs Remote Java Application type debug configuration
Drop to frame Allows to go back in execution to previous method in stack. Variable modifications will not be reversed
Thread dump All threads stacks Generate with: jstack pid Kill -3 pid Win: ctrl + pause/break Tools (visualvm,..)
Problems analyzable by thread dumps Deadlock Thread contention Low performance CPU usage without profilers. Take multiple thread dumps and compare
Thread statuses NEW: The thread is created but has not been processed yet. RUNNABLE: The thread is occupying the CPU and processing a task. BLOCKED: The thread is waiting for a different thread to release its lock in order to get the monitor lock. WAITING: The thread is waiting by using a wait, join or park method. TIMED_WAITING: The thread is waiting by using a sleep, wait, join or park method. There is max time.
Thread types Non-Daemon Main thread Daemon Will stop running If all non-daemon threads have finished running Usually several created if only one explicit thread
Memory dump (Heap dump) Heap dump in hprof format JVM details System properties Thread dump ( JVM 1.6+ ) Snapshot of all objects. Generate with jmap -dump:[live,]file=<filename> pid -XX:+HeapDumpOnOutOfMemoryError
Analyzing memory dumps Find memory leaks Detect large objects High memory usage Save the memory state for later debugging
Java crash files hs_err_pid*.log Fatal error log Core dump Heap dump and more
Fatal Error Log Is created when JVM crashes Shows low level info to understand the root cause of crash Saved as hs_err_pid<nr>.log or XX:ErrorFile= In working directory or /tmp
Fatal error log contents The operating exception or signal that provoked the fatal error Version and configuration information Details on the thread that provoked the fatal error and thread's stack trace The list of running threads and their state Summary information about the heap The list of native libraries loaded Command line arguments Environment variables Details about the operating system and CPU
MBeans aka JMX API Give additional information about JVM Memory and GC Execute GC CPU System Threads Many tools work on top of it Allows to run operations
Tools jconsole Monitoring tool MBeans jvisualvm All-in-one java troubleshooting tool Lightweight profiler Plugin system (VisualGC) Java Mission Control Advanced monitoring Flight recorder
Homework 14 https://github.com/zeroturnaround/jf-hw-performance This project has an implemention for the N-puzzle ( http://en.wikipedia.org/wiki/fifteen_puzzle ). The board is a little bit bigger though, 5x5. The project uses the class org.zt.jf.perf.main for benchmarking the implementation. It uses the A* algorithm by default but is bundled with depth first and breadth first approaches also. Your task is to Probably you want some custom flags here. Describe in a sentence or two why the program is as slow as it is Make whatever source code changes you see fit so that the program would run faster. Of course it needs to produce the same results and solve the same problem :) Please provide the code changes and also measurements as how much were you able to improve the speed
References Eclipse debugging tutorial http://goo.gl/cxigmf Fatal error log http://goo.gl/xepbpl