Hotswap Agent for Java Virtual Machine (Part 2)

This is the second post in the series of posts on writing Hotswap agent for Java Virtual Machine. In the previous post, we saw an higher level overview about the requirements and specification on how it can be done. In this post, we will drill down to the details. I am also planning to write few more posts on implementing this agent using Java Debug Interface. Also, once you understand this Hotswap agent, you can write a lot of tools using Java Debug Interface. The rest of the post gives the details of how to write an agent using JDI.

Java Debug Interface is a programming interface which lets us to write agents that interact with a live JVM. The interaction is of two types. First, JDI gives infrastructure to receive events from the JVM. For example, whenever an exception is thrown, JVM publishes an event. With the help of JDI an in-process agent or an agent running as different process in the same or different system can consume the event. Secondly, with the help of infrastruture given by JDI, the agent can also control JVM. The events together with controlling of JVM helps developers to write tools such as debuggers and profilers.

When you are going to write an agent (a program that monitors and managers remote JVM) using JDI, the first thing that you have to do is to know how are you going to connect to JVM. There are mutiple connectors available. Each connector differ in the way on how they interact with the JVM. For example, LaunchingConnector helps you to launch a JVM before connecting to it but ListeningConnector simply listens to a running JVM. Next thing is the transport mechanism, the method of communication between JVM and the agent.

After deciding both of these, you need connect to JVM. If the connection is successful, you will get an instance of JVM. With the remote JVM object, you can subscribe for specific event by through JDI request. Apart from this, using classes and methods in JDI, the agent can also control JVM such as stopping a thread, running garbage collection, redefine and reload classes etc. The following is the list of events that an agent can subscribe for.

AccessWatchpointEvent
BreakpointEvent
ClassPrepareEvent
ClassUnloadEvent
Event
EventIterator
EventQueue
EventSet
ExceptionEvent
LocatableEvent
MethodEntryEvent
MethodExitEvent
ModificationWatchpointEvent
StepEvent
ThreadDeathEvent
ThreadStartEvent
VMDeathEvent
VMDisconnectEvent
VMStartEvent
WatchpointEvent

If you want to write a simple tool to reload classes on the fly, you have to identify Connector, Transport, subscribe for events like JVM Start, JVM End. You have to use redefineClasses method and then reload the classes into the JVM. I believe, this post would have given you some idea on how to write a Hotswap agent. In the next post, we will see the implementation of Hotswap agent with the help of code.

Hotswap Agent for Java Virtual Machine (Part 1)

Before joining my company and in fact until two years after I joined my company, C, 8085/8086 ALP and Perl are the programming languages I knew. I learned C and ALP at college and Perl at my office to write a simple CGI utility. Two years later, I started to learn Java as I was moved to development team and I started to learn Java with certain amount of dislike. After a short period of time, I started to read about Java Virtual Machine specification and writing tools with the help of JPDA. Writing tools using JDI/JPDA is relatively simple as JPDA gives you enough infrastructure. This post contains specification/requirements for writing a small and powerful agent to reload classes of live JVM. As you may know, Java source code is compiled and bytecodes are produced. These bytecodes (generally .class files) are loaded into JVM and are much like machine instruction but the fact is that only JVM can understand it. These bytecodes are your program and decides how your application is executed.

If you are a developer, your daily job might be writing code or fixing bugs or both. During development, you may need to change the logic of your program, recompile the source and restart the application. Restarting the application is stopping the running JVM and starting a new JVM process. This is a very lengthly process if your work involves changes to source code multiple times. Sun HotSpot VM comes with a feature called HotSwap. Using this feature one can replace the classes that are loaded in the JVM. Once reloaded, the objects that are already created also takes effect with new changes. This tool will improve the productivity of developers when frequent restart of the applications is required. Here is the specification.

Specification

Write a simple tool which let you to reload classes in a running JVM without restarting your application. Also provide a simple user interface (probably using SWING).

Steps

1. Use Java Debug Interface API to connect to remote JVM. In order to connect to remote JVM, you the hostname/ip address of the remote box and port number on which your JVM runs. In order to hotswap the classes, you need start JVM in debug mode and if you start JVM using "socket" debugger.

2. Also subscribe for few important events such as JVM Exit, Disconnect Event. (for more info refer Java Debug Interface API Spec).

3. If the connection is successful, you get an instance of the remote JVM and you can once again use JDI to replace classes.

4. You have to write the logic of reading the class file (flat file) from the file system and give to JDI. JDI pumps the class file to remote JVM which reloads the class after making lot of checks.

In next couple of days, I m planning to write a post on how to do this with a small example (thanks to Veeru for pointing this out).