The problem is that there is no officially documented JVMTI hook that allows the user to find out exactly what the currently running thread is doing that is safe to run in a signal handler. The official way of getting a stack trace, the GetStackTrace function, isn't safe to be called in an asynchronous way... It turns out that the kind folks who wrote the Java virtual machine were fully aware of this, and provided an undocumented interface for this type of profiling.He goes on to discuss the implementation with plenty of Java and JNI code, and gets it to work under most circumstances. There are only one or two kinks he'd like to fix. Check it out!
Jeremy Mason talks about an experiment he did recently: use JVMTI and Linux SIGPROF together to asynchronously fetch the stack trace of a running Java program. He covers JVMTI, SIGPROF, and how he used JNI and lots of brain power to achieve his objective. Jeremy writes:
- Posted by: Eugene Ciurana
- Posted on: May 31 2007 09:31 EDT
Is there really a big need for this? I have been quite happy with SIGQUIT (3) and on my last project also the nice JVM MBean provided by BEA JRockIt. From what I gather, the difference is in synchronous vs. asynchronous. Could someone give real-life examples were this is necessary? Oh joy be the day, when people asks to have JNI code loaded, which hooks into unsupported, seemingly volatile and "works under most circumstances" APIs. Personally, I need to serious selling points for the asynchronous benefit before giving this another thought. Not dis'ing Jeremy's work, it's great that he took the time to investigate this and also the time to write about it!