BTrace == Java’s DTrace (i.e. awesome)
I’ve spent the last few days of my job at SFR on improving the build system and moving the integration env. to a 64bit system. While I had my hands under the hood, I also upgraded the platform to Java 6 (JDK 6 actually, you’ll see why). I wanted to try some BTrace scripts to see how useful it would be to debug live production apps running in a Java VM. Having played with DTrace on OpenSolaris last year during my time working for Sun Microsystems, I longed for this kind of dynamic instrumentation tool.
According to the BTrace open source project: “BTrace is a safe, dynamic tracing tool for the Java platform. BTrace can be used to dynamically trace a running Java program (similar to DTrace for OpenSolaris applications and OS). BTrace dynamically instruments the classes of the target application to inject tracing code (”bytecode tracing”). Tracing code is expressed in Java programming language.”.
I don’t know about you, but having this kind of power when trying to pinpoint the source of a weird bug… you know the type that occurs only with the load / bandwidth of a production environment, is pretty useful.
The best part is that, contrary to DTrace, you write you BTrace probes as a simple Java class. You don’t even need to compile it ahead of time, the btrace launcher will compile it for you (that’s partly why you need the JDK, but also because BTrace relies on some advanced bytecode hotswap bit twiddling only available in the JDK hotspot). The overhead is extremely low, albeit you can always kill the instrumented VM by writing lousy probes.
The samples provided in the BTrace distribution are extremely valuable as they provide a good starting point for most needs (e.g. slapping together a simple profiling histogram for method calls count over some packages / classes). BTrace heavily relies on Java 5’s annotations, which leaves very little actual java code for you to write. Obviously, this implies that your probing code runs in constant time and doesn’t modify in any way the state of the probed program. They strongly advocate the use of JSR166’s (java.util.concurrent) Atomic types wrappers and concurrent data structures when doing your profiling stats.