This week's book giveaway is in the Jobs Discussion forum.
We're giving away four copies of Java Interview Guide and have Anthony DePalma on-line!
See this thread for details.
The moose likes Threads and Synchronization and the fly likes JVMTI Behavior Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "JVMTI Behavior" Watch "JVMTI Behavior" New topic

JVMTI Behavior

Saul Tocsin

Joined: Feb 25, 2012
Posts: 14
Hi All,

I'm not sure where to post this because I see no forum expressly devoted to debugging. So I'll post it here, alongside my last post because they are related.

Not convinced that the JMX-based approach I outlined
in my other post is sufficient, I began to look at the JVM Tool Interface.

Fundamental questions about JVMTI: when the JVM calls back into the client ("agent") DLL or .so, are the threads I might be interested in monitoring suspended? And by "suspended" I don't mean in the Thread.State sense. I mean only, will they change while I am trying to inquire about why they are BLOCKED (for example)?

Related question: if I call into JVMTI's getThreadState which, I think, is NOT a call back function, will the JVM's threads continue to run which the JVM processes this call?


Mohamed Sanaulla
Saloon Keeper

Joined: Sep 08, 2007
Posts: 3152

I had created a JVMTI agent and another front end for capturing the results, that was 2 years ago and I quite dont remember lot of it. From what I can remember- I think the JVMTI Agent (.dll/so) would not impact the function of the java application it is monitoring.
Yes getThreadState is not a callback function and the API documentation doesn't state anything about the call impacting the JVM threads.

Mohamed Sanaulla | My Blog
Saul Tocsin

Joined: Feb 25, 2012
Posts: 14
Hi Mohamed,

Thank you for the reply.

Can you say more concerning "....the JVMTI Agent (.dll/so) would not impact the function of the java application it is monitoring"?

My immediate concern is the state of monitored thread when the JVM calls back into the agent (JVMTI client). Specifically, if the monitored thread continues to run - and so change state - then information gathered about that thread is incoherent, and therefore useless.

Other concerns are:

a. is there a call I can make from my agent into the JVM that will allow me to suspend a thread's execution so that I can get a coherent picture of its state?
b. if the JVM makes a call back to a method in my agent, can that method safely call into the JVM?

Thanks again.

I agree. Here's the link:
subject: JVMTI Behavior
It's not a secret anymore!