1 Reply Latest reply on May 28, 2012 6:00 PM by 939796

    Use of JVMTI for state sampling

      Hi All,

      I am working on a state sampling monitor. Its basic functions are:

      a. wake up periodically
      b. get thread state for threads of interest (e.g., some application's threads)
      c. if the thread is blocked (BLOCKED, WAITING,..) then look more closely to get the monitor lock it's waiting on
      d. record all this info in some kind of dictionary | array

      The state sampling monitor runs concurrently with the application it's monitoring. When all is said and done, the recorded data should have entries like this (expressed in English): "thread 1 was found to be blocked 1000 times waiting on monitor lock A; thread 1 was found to be runnable 500 times; thread 1 was found to be blocked 9999 times waiting on monitor lock B," and so on.

      It occurred to me that JVMTI might be a good way of accomplishing this. Specifically, I thought I might be able to use its event callbacks:


      I have some questions:

      1. Will these event callbacks cover ALL types of thread waits?
      2. Is there any way to determine that a thread is blocked because it’s waiting on I/O?
      3. If the answer to (2) is “yes,” then is there any way to learn something about the I/O in question, e.g., what file | device it’s waiting on?

      I had first thought to accomplish this via ThreadMXBean's getThreadInfo method. But I was concerned, perhaps needlessly, about the consistency of the information it returns. Specifically, does ThreadMXBean’s method

      ThreadInfo[] getThreadInfo(long[] ids, boolean lockedMonitors, boolean lockedSynchronizers)

      return a consistent representation of a thread? That is, suppose the following sequence:

      a. When getThreadInfo is called, a target thread is BLOCKED, waiting on a monitor lock
      b. The getThreadInfo call returns AND the formerly blocked target thread happens to start running
      c. ThreadInfo.getThreadState is called on the ThreadInfo object that represents the target thread
      d. ThreadInfo.getLockName is called on the ThreadInfo object that represents the target thread

      Will (c) return BLOCKED? (remember, the target thread is now running)

      Will (d) return the lock name that the target thread was waiting on at time (a)?

      Thanks for your help.