Here again sending SIGQUIT signal to application will help. This will invoke the deadlock detector of VM and will tell you if there is any java level deadlock in your application threads.

You can obtain the stack trace of the java threads of your application by sending SIGQUIT signal (ctrl+\ on unix systems and ctrl+break on windows systems) to your running application.

For getting the stack trace of native threads, you need to use native debugging tools such as pstack or dbx/gdb on unix systems and windbg on Windows.

The parent process uses these streams(Process.getOutputStream(), Process.getInputStream(), Process.getErrorStream()) to feed input to and get output from the subprocess. Because some native platforms provide limited buffer size for standard input and output streams, so you need to promptly consume the input and output streams of the subprocess, otherwise the subprocess may block or even deadlock.

There are a couple of things you can try on Solaris (unfortunately, there's only one thread model available with Windows/Linux). Using bound threads when the application uses few threads may benefit you. Try -XX:+UseBoundThreads. Also, you can try to load the alternate libthread.so in /usr/lib/lwp/ on Solaris 8 by changing your LD_LIBRARY_PATH to include /usr/lib/lwp before /usr/lib. Both of these give better throughput and system utilization for certain applications, especially those using fewer threads. For applications using many threads, /usr/lib/libthread.so and unbound threads are still the best bet. Of course, see using -Xconcurrentio (above) for applications with many threads.

You can try running your application with -XX:+PrintGCDetails -XX:+PrintGCTimeStamps. These VM options will print details on how much time is being spent in the garbage collection of each generation.

111691K->111691K means that the New generation collection was not attempted and rather a mark-sweep collection was done in which New generation got emptied out and survivors from New generation got promoted to tenured generation and hence the increase in tenured generation occupancy.

You are seeing a crash somewhere in the native code of your application or VM. To debug this crash, run your application with -XX:+ShowMessageBoxOnError. Upon crash, you will see a message box pop up with message "Do you want to debug this crash?". Press 'yes' and it would give the control to the default debugger on your system.

You can set Windbg, Visual Studio or any other debugger of your choice as your default debugger.

This is hotspot error log file and it contains information about the crash and the system on which the crash happened. e.g. it contains the stack trace of the crashing thread, register values at the time of crash, information about all the shared libraries loaded by the application and the system details on which the problem occurred.

If you have a looping Java application you need to find which threads in the application are consuming CPU time and then look at the stack traces of those threads.

- Run prstat to identify the threads consuming most of the cpu time. Find the process with ps or jps. Then run prstat -L -p pid on the process

- Get a thread dump by sending a SIGQUIT signal to the process (kill -3 or ctrl-break): examining the stack traces of threads which are consuming cpu time might give a clue about the looping.