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?
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.
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?