The concurrency detector

One of the things I love to do is to check code for concurrency issues (for example in audits). If a system is aware of concurrency from day one, checking for concurrency problems is less hard (although it still can be very complex) because it is much clearer which objects are and are not thread safe. But in most cases the systems I check are systems that already have been build and thread safety didn’t always have the highest priority. To make it even more problematic, if the system contains hundreds or even thousands of classes, figuring out which object could have problems is almost impossible.

So I started thinking about a way to assist me to find problems; to see which objects are used by multiple threads. That is how the ‘concurrency detector’ was born. At the moment it used AOP (AspectJ) to add the ‘concurrency detection aspect’ to classes that I’m interested in. This aspect stores which thread has touched which field of which object. And based on this information it is quite easy to infer which objects are used by multiple threads. From that point on it is manual work to see if there are really problems, but it is a lot better than having no assistance at all. From time to time it writes all information to some HTML report and the system can be influenced by JMX (turned off/on, reset etc).

In the near future I want to add the following stuff:

  1. more informative HTML reports: maximum numbers of writes/read by a thread, maximum total number of reads/writes etc
  2. sortable tables in the HTML reports
  3. problem ‘hotspots': e.g. if an object has multiple reads and writes by multiple thread, it is more likely to have concurrency problems than a single write and a multiple reads. This helps getting ‘the biggest bang for the bug’
  4. dynamic AOP (dynamic pointcuts): to add advice on classes on the fly. At the moment I’m using load time weaving, but I’m not very happy with it. It could interfere with existing Java Agents, it only works on Java 5 (and higher) and I need to create a new jar every time I want to look at different packages/classes. It is not quite clear to me if or how AspectJ is able to deal with dynamic AOP.

If you are interested in this tool, please stay in touch with my blog. I still have to decide what I’m going to do with the product (probably make it Open Source). Without in depth concurrency knowledge, the tool is useless anyway.

About these ads

7 Responses to The concurrency detector

  1. Barend Garvelink says:

    Sounds very useful, I’ll keep an eye on the RSS feed!

  2. Raoul Duke says:

    Neat! I’d sort of vaguely thought (although lamely) along those lines tooafter reading up on some nifty deadlock tools coming out of academia.

  3. Collin says:

    Could this be a plugin for VisualVM? https://visualvm.dev.java.net/

  4. -FoX- says:

    Sounds like a neat tool!

    Another thing I was wondering about is if it is possible to create some framework that allows you to ‘unit test’ concurrent environments, enabling you to detect concurrency issues through some sort of testing?
    I was thinking about advicing instructions with locks, and monitoring them to see if other threads are influenced by this.. in fact, it is just like slowing down the execution enviroment and see if the system behaves differently.

    just some random thoughts :)

  5. pveentjer says:

    Hi Fox,

    There is some support for testing concurrent code on a functional level like: http://code.google.com/p/multithreadedtc/
    and for my concurrency project I created something as well:

    http://prometheus.codehaus.org

    ConTest is a tool that instruments bytecode so that the chance of different interleavings is increased; and this increases the chance to see (and fix) a problem. The site has just been updated (after 3 years of silence)

    http://www.alphaworks.ibm.com/tech/contest

    It is on my todo list :) But there is a lot of other stuff on it as well.

  6. pveentjer says:

    @Collin

    It certainly could be something to be used in VisualVM. It certainly is something to keep in mind, thanks.

  7. […] am now able to run my concurrency detector on large projects like JBoss instead of running out of […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: