{"id":2936,"date":"2013-11-30T15:15:03","date_gmt":"2013-11-30T15:15:03","guid":{"rendered":"http:\/\/dalelane.co.uk\/blog\/?p=2936"},"modified":"2013-12-01T11:05:40","modified_gmt":"2013-12-01T11:05:40","slug":"avoiding-monitor-contention-in-javas-double-parsedouble","status":"publish","type":"post","link":"https:\/\/dalelane.co.uk\/blog\/?p=2936","title":{"rendered":"Avoiding monitor contention in Java’s Double parseDouble"},"content":{"rendered":"

Overview<\/strong><\/p>\n

You can call Double.parseDouble<\/code> in Java to convert String representations of numbers like “1.234567” into a number representation. <\/p>\n

I needed to do this, a lot of times, from a lot of threads. And it was horrendously slow. <\/p>\n

In this post, I’ll explain why and what I did about it. <\/p>\n

Background (skip this if you don’t care why I had this problem!)<\/em><\/strong><\/p>\n

I’ve mentioned UIMA before<\/a> : an Apache framework for doing text analytics, that I use at work. One of the ways that it stores and moves around units of work is in XML files (called CAS files). <\/p>\n

For a particular task at work, I will have a lot of these. Thousands of them. I need to deserialize these, and parse and process the contents. The contents includes scores from the various analytics operations that are done on the contents of the CAS:<\/p>\n

<myElement
\n     myRawScore=\"1.2345678\"
\n     myThisScore=\"2.46801357\"
\n     myThatScore=\"1.35792468\"
\n     ... <\/code><\/p><\/blockquote>\n

Thousands of XML files, each containing several thousand numbers in String form. <\/p>\n

As part of the deserializing the CAS files, the UIMA library (specifically org.apache.uima.cas.impl.CASImpl<\/code>) was calling Double.parseDouble<\/code> 500,000,000 times or more. <\/p>\n

I’ve got 64 processor cores and lots of memory, so I kicked off 64 threads – each one processing an XML CAS file at a time. <\/p>\n

This took *ages*.<\/p>\n

<\/p>\n

The problem<\/strong><\/p>\n

I used Health Center<\/a> to have a look at what was going on. (Disclaimer: It’s an IBM tool, but it’s free and is awesome, so I don’t feel bad promoting it!)<\/em> <\/p>\n

It showed that although I had 64 worker threads, only one of them were running at any given moment while the other 63 were blocked. <\/p>\n

<\/a><\/p>\n

It showed that I was spending the majority of my time inside Double.parseDouble<\/code>, because one of the methods it calls (FloatingDecimal.big5pow<\/code>) is synchronized. <\/p>\n

<\/a><\/p>\n

The implementation of Double.parseDouble<\/code> is fast when used once, but it’s not well suited to being called hundreds of millions of times from multiple threads concurrently – the locking makes this very, very slow. <\/p>\n

The fix<\/strong><\/p>\n

It turns out that this is a known issue. There is a closed bug filed against Java (JI-9004591 – Monitor contention when calling Double.parseDouble from multiple threads<\/a>), but it’s been closed as fixed in Java 8. <\/p>\n

That would be helpful if Java 8 was actually released yet. I couldn’t wait for this. <\/p>\n

The workaround<\/strong><\/p>\n

I’ve written my own Double parser. <\/p>\n

It’s a kludgy workaround to be honest, based on the fact that I noticed that Integer.parseInt<\/code> and Long.parseLong<\/code> aren’t synchronized. I decided to try and use them instead. <\/p>\n

Consider the following decimal number:<\/p>\n

1234.5678<\/font><\/p>\n

Another way of expressing this is<\/p>\n

12345678 x 10-4<\/sup><\/font><\/p>\n

\nI can parse this using Integer.parseInt<\/code>.<\/p>\n

Integer.parseInt(\"12345678\") * Math.pow(10.0, -4))<\/code><\/p><\/blockquote>\n

So to parse any decimal number, I need to:<\/p>\n

    \n
  1. Do a bit of String munging
    Look for where the decimal point is, move it to the end of the String and count how many places I’ve moved it by.\n<\/li>\n
  2. Parse the munged String as an int (or a long if it’s too big to fit in an int)\n<\/li>\n
  3. Compensate by multiplying by an exponent that reverses the change<\/li>\n<\/ol>\n

    I did a little more. For example, to handle numbers that already have an exponent, I add\/subtract the number of places I moved the decimal point to the existing exponent. But this is the basic idea. <\/p>\n

    The source code for my workaround is here<\/a>.<\/p>\n