Win a copy of Learn Spring Security (video course) this week in the Spring forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

JVMTI Behavior

 
Saul Tocsin
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?

Thanks.

-Saul
 
Mohamed Sanaulla
Saloon Keeper
Posts: 3159
33
Google App Engine Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Saul Tocsin
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

-Saul
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic