Exciting Java Tools

I wanted to blog about some of the most exciting Java tools which I have come across. Sadly none of these tools are free but the technology which they implement is really impressive.

http://www.chrononsystems.com/

Chronon records a complete trace of the execution of a Java program. There are a couple of reasons why this is really cool.

Firstly, the actual logging mechanism is claimed to have a low enough impact that you could realistically run with Chronon all the time. The theory here is that when you hit a hard to reproduce bug you will always have enough information to investigate and fix the bug.

Secondly, Chronon have produced some excellent UI to get the most out of the collected trace files. The time travelling debugger allows you to step forwards and backwards through a trace file as if you were stepping through a live program. Even cooler is the post execution logging which allows the developer to add logging statements and have them be executed as if they were present when the trace file was captured. 

http://zeroturnaround.com/

The Sun Hotspot JVM includes support for a cool feature called Hotswap. This allows the body of Java methods to be updated on the fly while the JVM is running. The feature is nice but limited as a lot of things are not allowed - methods can't be added or removed, method signatures can't be changed, fields can't be added or removed etc.

ZeroTurnaround have managed to produce a system which runs within the standard Hotspot JVM and removes all of these limitations. This is really cool!

This technology has been packaged in two ways. JRebel allows developers to work on applications and change the code without restarting the JVM. LiveRebel does the same but is aimed at live upgrade of webapps without downtime. 

http://www.azulsystems.com/

Azul Systems have created a new garbage collector (C4) that claims to put an end to stop the world garbage collections. The promise is that this allows a single JVM to use 10s of GB of heap without having to endure periodic stop the world GCs that last several seconds.

The big side benefit of this work is that Azul have published lots of great information about the details of garbage collection.

One more thing

All the tools I have spoken about so far aren't free but there is one more tool which I should mention.

Eclipse is both free and excellent and is definitely the tool that makes the most difference to me every day that I work on Java code.

Java Live Thread Analyser

One of my most recent projects was motivated by a session using the excellent Visual VM tool. I was monitoring the startup of a Tomcat based application and watching the number of threads as a rough metric for how far along the startup was. The application I was monitoring has completely started when there are around 200 live threads out of around 300 started in total.

I was somewhat taken aback at the number of live threads which were being used and also the number of short lived threads which had been started. Who allocated all these threads? What are they all doing? Unfortunately many of the threads had not been named. A thread dump gives some clues about what live threads are doing but many threads were blocked in generic methods (e.g. Timers). What I really want is to capture the stack trace of all Thread allocations and track the lifetime of all threads.

This objective prompted me to write a tool which I've called the Java Live Thread Analyser (JLTA).

There are two main parts to JLTA.

1. A Java Agent allows me to collect the raw data and allow it to be downloaded over a TCP socket.
2. A Java SWT GUI to connect to the agent, download the raw data and summarise the results in a useful way.

The Agent collects data by making two transformations to the classes within the JVM. The Thread class is transformed to add a call to my tracking code from the end of all the Thread constructors. The Thread class and all subclasses are transformed to add a call to ky tracking code to the start and end of all run() methods. A Boolean thread local is used to make sure the run() method entry and exit are only handled once. This takes care of the case where a subclass calls into a superclass run() method. The tracking code attempts to detect when a Thread has been allocated by a Tomcat webapp by examining the context classloader of each Thread.

The GUI filters the collected data by grouping thread allocations by stack trace. Threads can be filtered based on their thread state, context and whether they have been given a name. The number of stack frames being used for grouping threads together can be limited.

I have published a static site describing this tool and linking to the appropriate files to download and use it.

Introduction

For the last couple of years I have been writing software in my spare time to solve problems I encounter and because I frankly enjoy coding.  For the last few months I have been enjoying getting to grips with Arduino hardware and blogging about it. Given this experience I thought it was time to start this new blog about my coding projects. In this blog I plan to talk both about new projects and some of my old projects. I have an existing static site which documents some of my projects. However, I thought that starting this blog would give me the opportunity to go into more of the technical details behind my projects.