This content has been marked as final. Show 4 replies
Well, yes and no. But I'm curious why crippling JVM operations with a pstack is not ok but stopping the process to walk its threads would be fine. ;-)
What version of the JVM? If JRE 1.5.0 or later, have you played at all with the HotSpot provider? Through that interface you can get closer to your Java threads. Sorry I can't whip up an example here off the top of my head, but that's where I'd start looking.
Thanks. The hope was that DTrace would work faster, much like 'pstack' worked faster before Solaris 10. It takes a long time to complete, and apparently during that time the process is stopped. I did not think that the HotSpot provider was available for the version of Java we are using, but now I see that it is:
Now, I have more to look into. Thank you.
Java(TM) 2 Runtime Environment, Standard Edition (IBM build 1.5.0_17-b04 20081210 solaris sparc (SR9)) Java HotSpot(TM) Server VM (build 1.5.0_17-b04, mixed mode) IBM Java ORB build orb50-20081120 (SR9) XML build XSLT4J Java 2.7.15 XML build IBM JAXP 1.3.9 XML build XML4J 4.4.14
My first suggestion: get the JRE 6 VM and drop it in. With a few exceptions, it will likely run your code as well or better than the JVM you're using. You'd at least want to consider it for your test environment.
If that's a non-starter for you, there is a dvm provider for 1.5; it's just not built in. Here's a good starting point for that:
There isn't a probe in the dvm set that gives you the primitives you need for your goal, but it's a start at least. If nothing else, trying it out makes a pretty good motivation for moving to Hotspot.
Java call stacks get pretty deep, especially in app server deployments. I'm not surprised to hear pstack might even gag on what might be very large and very many string dumps. Although I must say my first inclination with DTrace would be to see what's going on with pstack.