We can visualize resource starvation using an elaborate rendition of the Dining Philosophers Problem. This classic metaphor of resource allocation among processes was first introduced in 1971 by Edsger Dijkstra in his paper "Hierarchical Ordering of Sequential Processes." It's been a model and universal method for verifying theories on resource allocation ever since.

The metaphor goes like this: There are three well-known philosophers in an Asian bistro. Dinner is served but they are only given three chopsticks because the restaurant's supply truck has been stuck in a snow storm for a couple of days. Naturally each philosopher needs two chopsticks to eat his dinner and each is protected from interference while he uses a chopstick.

Plato skipped lunch that day and insists that he should have priority or else he'll faint. If he doesn't give up his chopsticks, the other philosophers won't be able to eat and eventually they'll starve. If Plato drops his chopsticks and immediately picks them up before the other philosophers can get them then they won't be able to eat and they'll eventually starve.

Dijkstra's Dining Philosophers Problem employed spaghetti and forks but I used chopsticks and Asian cuisine for a more realistic illustration since you can't eat spaghetti with a single chopstick (see Figure 1).

These are examples of resource starvation. You could also encounter deadlock. There are a couple of solutions like semaphores and monitors. But we won't think about solutions or deadlocks in this article. We'll focus on detecting resource starvation using IBM Thread and Monitor Dump Analyzer for Java.

What Is the IBM Thread and Monitor Dump Analyzer for Java?
During the runtime of a Java process, some Java Virtual Machines (JVMs) may not respond predictably and often seem to hang up for a long time or indefinitely (until the JVM shuts down). It's sometimes very challenging to determine the root causes of these sorts of problems.

By triggering Java thread dumps or Javacores when a Java process doesn't respond, it's possible to collect diagnostic information related to the JVM and a Java application captured at a particular point during execution.

On some platforms, a Javacore is known as "javadump." The code that creates a Javacore is part of the JVM. One can control it by using environment variables and runtime switches. By default, a Javacore occurs when the JVM terminates unexpectedly. A Javacore can also be triggered by sending specific signals to the JVM. Although a Javacore or javadump can occur in Solaris JVMs, much of the content of the Javacore is added by IBM and, so, is present only in IBM JVMs.

IBM Thread and Monitor Dump Analyzer for Java analyzes thread dumps/Javacores and diagnoses monitor locks and thread activities to identify the root causes of hangs, deadlocks, and resource contention or monitor bottlenecks. It can analyze IBM, Solaris, and HP-UX Java thread dumps from Java Virtual Machine 1.3.1, 1.4.x, 5.0, and 6.0

More than three years ago, I created IBM Thread and Monitor Dump Analyzer for Java as a garage project and spent thousands of hours during weeknights, weekends, and vacations to provide my clients and colleagues with something that can help diagnose these problems easily, motivated by the same reasons as my other garage projects like IBM HeapAnalyzer, IBM Pattern Modeling and Analysis Tool, and IBM Performance Analyzer for Java for Windows. All the algorithms used have been filed with the U.S. Patent and Trademark Office.

The widgetry was introduced to the public about two years ago through alphaWorks where it's been one of the top downloads for 30 consecutive months. It's recorded 23,296 downloads so far and it's been used by more than 14,600 companies, government agencies, research facilities, and universities worldwide (these statistics are good as of October 2008).

What Is a Thread Dump?
A Java thread dump is the one of the traces/dumps that JVM provides to help diagnosis a hang, deadlock, or monitor contention issue. It contains diagnostic information related to the JVM and a Java application captured at a point during execution. For example, the information can be a list of all the threads that run on a Java virtual machine. Usually thread dumps have more than just thread information. Thread dumps can produce information about the operating system, application environment, threads, stacks, locks, and memory. IBM Thread Dumps/Javacores provide much more information like core interface, data conversion/unicode, class, diagnosis, execution management/thread management, lock, execution engine, mixed mode interpreter, JIT (Just-in-Time compiler), storage/JVM heap, and hardware portability interface/extended hardware portability interface.

The contents and formats of Java thread dumps depend on the platform you're running on and the JVM provider.

Since a thread dump's format isn't a part of the SDK specification, each SDK vendor provides a unique thread dump format and its own JVM information. Currently IBM Thread and Monitor Dump Analyzer for Java understands IBM, Solaris, and HP-UX Java thread dump formats.

By default, IBM JVM thread dumps occur when the JVM terminates unexpectedly. A thread dump can also be triggered by sending specific signals to the JVM. Thread dumps are usually human readable text. In an IBM JVM, the thread dump is often called a Javadump or Javacore. Javacore is NOT the same as a core file, which is generated by a system dump.

Before IBM Thread and Monitor Dump Analyzer for Java was introduced, people had to manually check hundreds of threads in the thread dumps using their favorite editors. With IBM Thread and Monitor Dump Analyzer for Java, we can easily diagnose a variety of issues without reading through hundreds of thread stack traces.

Usually thread dumps aren't as large as heap dumps. Usually its size is around 1MB or less unless you have large number of threads or classes. It's not a big deal to manually review thread dumps if you only have a handful of threads running on your JVM. If you have hundreds of threads with dozens of Java monitors, it gets complicated.

How Does It Work?
This technology analyzes the information in each thread and provides diagnostic information, such as current thread information, the signal that caused the Javacore/Java heap information (maximum Java heap size, initial Java heap size, garbage collector counter, allocation failure counter, free Java heap size, and allocated Java heap size), number of runnable threads, total number of threads, number of monitors locked, native memory usage of each JVM component, and deadlock information.

IBM Thread and Monitor Dump Analyzer for Java also provides you with the recommended size of the Java heap cluster (applicable only to IBM SDK 1.4.2 and 1.3.1 SR7 or above) based on a heuristic analysis engine.

It compares each Javacore and provides process ID information for threads, a time stamp of the first Javacore, a time stamp of the last Javacore, the number of garbage collections a minute, the number of allocation failures a minute, the time between the first Javacore and the last Javacore, the number of hang suspects, and a list of hang suspects.

This technology also compares all monitor information in a Javacore and detects deadlock and resource contention or monitor bottlenecks, if there are any.

Let's Get Started
We can simulate a starvation problem with a simple Java application.

In DiningPhilosophers.java, we created three chopsticks, c1, c2, and c3 with the names, chopstick 1, chopstick 2, and chopstick3. Then we created three philosophers, p1, p2, and p3 with the names, Socrates, Plato, and Aristotle. You might have noticed that each philosopher's name has a suffix that represents a priority since we want to give Plato more of a chance to eat. Besides a name and priority, each philosopher is also given a left chopstick and a right chopstick. We start with each philosopher, p1, p2,  and p3 as shown in Listing 1. (Download Listings 1-6 here.)

In Chopstick.java, we just create a constructor, a getter, and a setter for the name of chopstick as shown in Listing 2

In Philosopher.java, we create a constructor, getters and setters for right and left chopsticks, and the philosopher's name. We also override the run() method in which we acquire Java's built-in monitors for left and right chopsticks and call the eat() method. In each () method, we pause for two seconds to simulate eating with the sleep() method but keep in mind that the philosopher is eating, not sleeping in the eat() method. See Listing 3.

Now let's put all the classes in a subdirectory, compile, and run them.

Compiling classes on a Unix platform
javac com/ibm/Jinwoo/starvation/DiningPhilosophers.java

Compiling classes on a Windows platform
javac com\ibm\jinwoo\starvation\DiningPhilosophers.java

I used the latest release of IBM Java virtual machine 6.0 (build jvmwi3260-20080816_22093 VM build 20080816_022093_lHdSMr) and another vendor's latest release of a Java virtual machine 6.0 when I wrote this for a fair comparison.

Executing classes
java com.ibm.jinwoo.starvation.DiningPhilosophers
Plato priority9 is eating with chopstick 3 and chopstick 1
Plato priority9 is eating with chopstick 3 and chopstick 1
Plato priority9 is eating with chopstick 3 and chopstick 1
Plato priority9 is eating with chopstick 3 and chopstick 1
Plato priority9 is eating with chopstick 3 and chopstick 1

Most of the time Plato will be eating and the other two philosophers will have less of a chance to eat. We can generate thread dumps by sending signal 3 to the process. On the Windows platform, you can use keyboard combinations like Ctrl-Break to send signal 3 to a process running in a command line window. Listing 4 has the results from the IBM Java virtual machine.

We used another vendor's Java virtual machine and redirected output to a file.

Generating thread dumps with another vendor's Java virtual machine
java com.ibm.jinwoo.starvation.DiningPhilosophers 1> sun.log

Now let's talk about thread dump a little more. In most Java platforms, thread dumps are generated when the JVM terminates unexpectedly because of an operating system signal or when the user enters a reserved key combination control-break on Windows, say. We can also generate thread dumps with IBM's JavaDump API: com.ibm.jvm.Dump.JavaDump() if you're running a IBM Java virtual machine.

You can use the kill command on most Unix systems:

• SIGQUIT[3] : JVM will not terminate
  

For example, kill -3 $PID

• SIGSEGV[11] : JVM will terminate
  

For example, kill -11 $PID

On the IBM WebSphere Application Server 5/6 environment, you can use wsadmin script to generate thread dumps:

wsadmin.sh -conntype SOAP -port <port number>
> set jvm [$AdminControl completeObjectName type=JVM,process=server1,*]
> $AdminControl invoke $jvm dumpThreads