Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Azul Releases Open Source jHiccup Tool to Provide Response Time Analysis of the Java Run

Azul Releases Open Source jHiccup Tool to Provide Response Time Analysis of the Java Run

This item in japanese

Azul Systems have today announced the release of jHiccup, an open source tool designed to measure the pauses and stalls (or "hiccups") associated with an application's underlying Java runtime platform. The new tool has some overlap with Azul's JitterMeter, but adds an Excel-based tool for creating graphical output. A Java-based tool for generating the charts is also planned. In addition, jHiccup is considerably easier to wrap-around an application; to start it you simply add jHiccup in front of the java -c command you use to start your application.

jHiccup captures, logs, and displays response time fluctuations in the runtime platform via "Hiccup charts". The tool does not measure delays caused by the application's code, but instead captures the stalls caused exclusively by the underlying runtime platform that would be visible to and affect any application thread running at the time of the stall. The technique used to accomplish this is trivially simple: jHiccup adds one thread to your application, which goes to sleep for 1ms, wakes up, and looks at how long it's been since it woke up last - if it's longer than 1ms it logs it internally. This then gives you a base-line on what the best possible response time could be.

A couple of "Hiccup charts" may be helpful here. The first shows an idle app on a quiet system. The top part of chart shows what the jHiccup system saw, with the percentiles for the overall run. Below, the tool provides a more detailed percentile sample, based on a 10,000 point percentile sample. Were the system (as opposed to the application) busier, we'd see an increased numbers of stalls, as the scheduler steals more of the application's time.

Idle System

The second image below shows a real-world example, from a telco billing application running on Hotspot using the CMS collector. By correlating this with the GC logs, we can tell that what we're seeing here are the minor and major GC events. CMS is a generational collector, which segregates objects into young generation and old generation, and preferentially collects younger objects. The app, as is somewhat typical of these kind of telco apps, has a hard time in the young generation, since it tracks lots of sessions that last for a few seconds and die. As a result, the sessions tend to get collected a lot in the young generation. The larger spike will be an old generation pause.

Telco App

jHiccup provides an easy way to work out where you should be spending your tuning efforts, by showing you how much of a given performance problem is in the application itself, and how much is down to other factors, such as the Java Virtual Machine (JVM), operating system, hypervisor (if used) and hardware. The tool is available for free download at, and is released as open source code under the Creative Commons license.

Rate this Article