wood burning stoves*
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 Android Security Essentials Live Lessons this week in the Android 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: 3068

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: http://aspose.com/file-tools
subject: JVMTI Behavior
Similar Threads
Thread Problem
Is there a thread that runs outside the jvm
How to force garbage collection in jdk 1.5
HFEJB Page 483
ThreadPoolExecutor getting stuck