JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 152 contents

Simple reasoning tells you that the combination of the following three things makes for an inherently unstable system that can cause serious systemic damage:

1. Having bugs;
2. No automated systemwide ability to monitor, shutdown and move into a failsafe mode;
3. Being fast;

1. Bugs means the system is potentially unstable. But most systems have bugs and many are fairly stable, because most bugs are resource stabilising: they cause failures in subsystems that prevent the subsystems from proceeding rather than causing damage. The kind of bugs that cause systemic damage need to enable "runaway" damage - there are always some of these, they're just rarer;
2. Systemwide failsafety would guarantee that the system is much more stable in the face of hitting a bug but these safe-modes are only ever built into life-critical software (e.g. nuclear/aircraft/rocket control and life support systems).
3. A slow system hitting a bug that causes "runaway" systemic damage has much more time to be shutdown before the damage becomes serious. The faster the system, the more likely the damage will be serious before it can be halted.

A note from this newsletter's sponsor

All this sounds a little esoteric, so how about I give you a real example that lost nearly half a billion dollars? Many of you will already have heard of Knight Capital's disastrous trading crash in 2012. This was caused by precisely the combination above: (1) a bug causing every trade to lose a little bit of money managed to get out to the production system; (2) there was either no automated systemwide monitoring for excessive loss, or else no automated capability to turn off trading; (3) the system was sufficiently fast that by the time it could be stopped, nearly half a billion dollars had already been lost. Note that the bug on it's own was not what caused the damage, it was the combination of repeatedly hitting it in a short time frame and lack of timely shutdown.

You might say that's an extreme example. But the only difference here is that the runaway system caused such an obviously large monetary loss. The faster your system, the more damage it can cause in a runaway situation. If the quest for ever lower-latency is not matched with a parallel quest for automated monitoring, control and failsafety features, then we're just storing up catastrophic failure for the future. The faster a system can go, the faster it can utilise a bug, and the faster bad things can happen before someone notices and stops it. You should always consider what will stop your system in time if it hits a runaway bug.

Now on to all our usual links to Java performance tools, news, articles and, as ever, all the extracted tips from all of this month's referenced articles.

A note from this newsletter's sponsor

News

Java performance tuning related news.

• JProfiler 8.0 released
• Some GC benchmark tests based on heaptrasher
• Reactor framework for aynchronous Java applications is released
• Keccak: The New SHA-3 Encryption Standard (probably fast enough)

Tools

Java performance tuning related tools.

• Collections.newSetFromMap(new ConcurrentHashMap<T,Boolean>()) gives you a concurrent set
• Performance-optimized Java implementations of the five SHA-3 finalists: BLAKE, Gr?stl, JH, Keccak, and Skein
• heaptrasher tool for testing impact of memory allocation patterns on gc performance
• Reactor - a foundation for asynchronous applications on the JVM

A note from this newsletter's sponsor

Articles

• Scaling my Server (William Edwards/williamedwardscoder)
• The 10 Deadly Sins Against Scalability (Todd Hoff/highscalability)
• G1: One Garbage Collector To Rule Them All (Monica Beckwith/infoQ)
• Most Commonly Missed Application Performance Issues (David Spark/newrelic)
• Fix Memory Leaks in Java Production Applications (Andreas Grabner/Java Developers Journal)
• Performance Tuning Face-Off (Vikram Gupta, Ben Evans, Charlie Hunt, Kirk Pepperdine, Martin Thompson, Monica Beckwith/infoQ)

Jack Shirazi

Back to newsletter 152 contents