JVMTI allows you to do a couple of useful things:
- Query all objects of a particular class and iterate over them to see what other objects are reachable from those classes. This also allows you to analyse the amount of heap consumed by certain classes, like singletons or HTTP sessions.
- Native method entry / exit. A bytecode instrumentation implementation for execution profiling is more efficient though, because it only hits the classes that are instrumented.
- Redefine classes at runtime. Useful for instrumenting/deinstrumenting classes on demand. This also allows you to run a profiler in production at no overhead.
- Analyse thread contention on synchronized blocks.
- Single step through the code to analyse code coverage. This should probably only be done during unit testing.
Ideally, I wish to run a GUI on top of the daemon with some command abilities, so that a control socket into the JVM can be used to send commands to the profiling application. This GUI is likely to become some sort of simple Tomcat / Struts application that renders a couple of views in real-time on a webserver, based on the received information so far. That can also be used to print heap memory usage / changes in realtime.
The idea is to do the following:
- Collect real-time information about code execution, avg/min/max.
- Collect code coverage statistics per class and method.
- Instrument classes at runtime to analyse method execution timings.
- Request memory usage of reachable classes from a particular class type and analyse this over time when the application is running.
- Request memory usage of all objects per class type and put this into a list / diagram.
- Send garbage collection requests at runtime for analysing memory leaks and the impact of long-running sessions.
- Deinstrument classes on demand.
- Analyse thread contention.
- ... Some more features in the future.
No comments:
Post a Comment