Late binding agents and fun times for the tool maker!

A few months ago, I highlighted an update to jconsole that allows it connect to applications that weren't started with special command line options. This ability to connect to a running application isn't unique to jconsole. When the NetBeans Profiler first appeared (as JFluid) it included a similar feature that allowed it to attach, apply instrumentation, and profile an application without needing to restart it with the profiler agent. At the time JFluid ran on a customized release of J2SE 1.4.x. The underlying implementation was very different, but the general idea is the same. There are many improvements in Mustang that mean that this ability to attach, start monitoring agents or instrumentation-based agents, is available to anyone developing tools. Today, I thought I might write up a few words on this topic.

First, some background. When I use the term "tool agent" I'm talking about the piece of the tool that runs in-process in the same VM as the application. Typically, tools are architected so that there is a "front-end" that the user interacts with, and a "back-end" that runs in the VM with the application. We see this general architecture with many of the profiling tools today. You'll also see essentially the same thing with the debugger architecture, or with JMX tools that connect to the JMX agent running in the target application. Agents doing exact and sample based profiling, space profiling, coverage analysis and so on are often developed as native agents (in C/C++) and make use of the JVM Tool Interface. Agents doing fine-grain monitoring, execution time profiling, journaling, and other tasks that make use of bytecode instrumentation are developed in the Java Language and make use of the instrumentation support provided by java.lang.instrument.

So how does a tool load its agent into a running application? In Mustang we have included the Attach API. This is a very simple API to bootstrap agents into a running application. The API is a Sun-specific API and is included in the JDK for use by tools (it can of course attach to applications that are deployed with the JRE). The VirtualMachine class is used to attach to an application. Once attached, the loadAgent or loadAgentLibrary methods can be used to load and start an agent. There is also a list method which can be used to enumerate the user's Java virtual machines (useful if you want to prompt a user to select the application to be monitored or profiled).

So what can an agent do once it is loaded in a running application? In the case of native agents using the JVM Tool Interface then it depends on the capabilities that the VM is able to provide in the live phase. Many of the capabilities needed by a fully featured debugger for example, are only available in the onload phase because they require special initialization or code generation that is only done at startup. Profilers starting in a running application will typically require the capabilities that will allow it instrument classes that are already loaded, instrument new classes as they are loaded, and perhaps tag objects and classes. In Mustang, these capabilities are always available in the HotSpot Server VM. Most are available in the HotSpot Client VM too except that the ability to instrument classes that are loaded from the shared archive (a short term implementation detail that will get resovled in time). For Java Lanaguage agents doing instrumentation then the story is the same - they can add ClassFileTransformers to instrument classes that are subsequently loaded, or retransform and instrument already loaded classes. Another aspect to instrumentation is that agents will often need to instrument classes so that they invoke methods on supporting classes provided by the tool. When an agent is loaded into a running application these supporting classes may not be available but Mustang has methods to make the supporting classes available for the bootstrap class loader or the system class loader. Many Java Language agents (like the JMX agent) won't be concerned with byetcode instrumentation - instead they will (for example) make use of package so that the tool can obtain telemetry information and manage the VM.

So now that we know what the agent can do you might wonder about security. This is very important and we've taken the position that there shouldn't be any suprises. That means that a tool shouldn't be able to interact with an application that won't normally be allowed by the security on the operation system. For UNIX environments this means that the tool must have the same effective uid/gid as the target application. On Windows, the implementation can only be used to attach to applications that you have privilege to open and interact with. So if Alice is running a memory profiler then she will only be able to attach to her own applications. She won't be able to attach her profiler to Bob's application that is churning out the winning numbers for next week's lottery.

So that's a brief overview of the late-binding agent support in Mustang. As you can see, all the major pieces to allow tools attach, observe, and profile a running application are in place. Fun times for the tool maker.


hi i m amar

Posted by ambar on January 30, 2007 at 03:00 PM PST #

Post a Comment:
Comments are closed for this entry.



Top Tags
« July 2016

No bookmarks in folder