My Workday

G1 collector is concurrent and parallel with more predictability and better useability. It splits the heap into regions and young and old generational spaces are organized in sets of regions. This eliminates the need to fine tune “NewSize/MaxNewSize”. G1 also provides incremental compaction in those regions by “evacuating” the regions that are full and fragmented. To try this G1 collector, you’ll need the aforementioned Fix Pack/Update and the following JVM options:

-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC

In addition, the following options can be used to adjust G1’s characteristics:

To set the max GC pause time goal in milliseconds that G1 will attempt to meet:

-XX:MaxGCPauseMillis

To set the time interval over which GC pauses totaling up to MaxGCPauseMillis may take place:

-XX:GCPauseIntervalMillis

For more information about G1 (how it operates, more options, etc.) see Java HotSpot Garbage Collection.



Hung, Deadlocked, or Looping Process

• Print thread stack for all Java threads:
  • Control-\
  • kill -QUIT pid
  • jstack pid (or jstack -F pid if jstack pid does not respond)
• Detect deadlocks:
  • Request deadlock detection: JConsole tool, Threads tab
  • Print information on deadlocked threads: Control-\
  • Print list of concurrent locks owned by each thread: -XX:+PrintConcurrentLocks set, then Control-\
  • Print lock information for a process: jstack -l pid
• Get a heap histogram for a process:
  • Start Java process with -XX:+PrintClassHistogram, then Control-\
  • jmap -histo pid (with -F option if pid does not respond)
• Dump Java heap for a process in binary format to file:
  • jmap -dump:format=b,file=filename pid (with -F option if pid does not respond)
• Print shared object mappings for a process:
  • jmap pid
• Print heap summary for a process:
  • Control-\
  • jmap -heap pid
• Print finalization information for a process:
  • jmap -finalizerinfo pid
• Attach the command-line debugger to a process:
  • jdb -connect sun.jvm.hotspot.jdi.SAPIDAttachingConnector:pid=pid

Post-mortem Diagnostics, Memory Leaks

• Examine the fatal error log file. Default file name is hs_err_pidpid.log in the working-directory.
• Create a heap dump:
  • Start the application with HPROF enabled: java -agentlib:hprof=file=file,format=bapplication; then Control-\
  • Start the application with HPROF enabled: java -agentlib:hprof=heap=dump application
  • JConsole tool, MBeans tab
  • Start VM with -XX:+HeapDumpOnOutOfMemoryError; if OutOfMemoryError is thrown, VM generates a heap dump.
• Browse Java heap dump:
  • jhat heap-dump-file
• Dump Java heap from core file in binary format to a file:
  • jmap -dump:format=b,file=filename corefile
• Get a heap histogram for a process:
  • Start Java process with -XX:+PrintClassHistogram, then Control-\
  • jmap -histo pid (with -F option if pid does not respond)
• Get a heap histogram from a core file:
  • jmap -histo corefile
• Print shared object mappings from a core file:
  • jmap corefile
• Print heap summary from a core file:
  • jmap -heap corefile
• Print finalization information from a core file:
  • jmap -finalizerinfo corefile
• Print Java configuration information from a core file:
  • jinfo corefile
• Print thread trace from a core file:
  • jstack corefile
• Print lock information from a core file:
  • jstack -l corefile
• Attach the command-line debugger to a core file on the same machine:
  • jdb -connect sun.jvm.hotspot.jdi.SACoreAttachingConnector:javaExecutable=path,core=corefile
• Attach the command-line debugger to a core file on a different machine:
  • On the machine with the core file: jsadebugd path corefile
    and on the machine with the debugger: jdb -connect sun.jvm.hotspot.jdi.SADebugServerAttachingConnector:debugServerName=machine
• libumem can be used to debug memory leaks.