DevPartner Java and Wait Time in Performance Analysis



What is the definition of the Wait Time parameter in the performance analysis session file?


Wait time includes time spent in other threads (eg, when the O/S preempts. Actually, wait time is just clockTime - threadTime.

Thread time for wait() operations can, generally speaking, be negligible. Calls to Windows API functions like 'WaitForSingleObject' exhibit this type of behavior, too.

However, java.lang.Object.wait() has much more code behind it than a simple trap into the O/S to wait. Looking at the SCSL sources, it goes through a couple of C functions and does things like adding the thread to a list of waiters, on a MP system doing a short spinlock & removing the thread from the list of waiters when it returns.

I imagine what you're seeing is some combination of events that make this wait() call expensive - well, expensive compared to the wait above, anyway. I haven't seen anything in Java to indicate that the presence of a timeout makes a wait more expensive, but it's reasonable to consider that as a possibility, I guess. Perhaps Java has a built in fast-path shortcut where the object was already signaled or something like that that just happens to fall (in your program) when you call wait without a timeout.

Certainly the mechanism we use for thread-time detection - or our instrumentation - does nothing special with a wait() call that it doesn't do for anything else.

I do have a more practical suggestion, however - if seeing this information is skewing your performance data, I suggest you exclude packages of utility classes. This will have the effect of rolling the performance data from these utility classes up into code you might be more willing (or able) to optimize. (That is, you'll see who is calling semWait the 38 times with a timeout). You can get at this data with the call-graph right now (by browsing through parent methods), but I find using exclusions in this way to be quite intuitive (which is why it's so helpful to exclude the system libraries in this manner)

Old KB# 11247
Comment List
Related Discussions