Two bug fixes in JDK6u34 worthy of note

JDKu34 fixes a lot of bugs but two, in particular, struck me as particularly worthy of note.

  • Bug 7027300 – Unsynchronized HashMap access causes endless loop
  • Bug 6941923 – RFE: Handling large log files produced by long running Java Applications

The first fix really made me laugh as this problem has existed for so long, been widely written about on the web and plagued many who made the rather novice and deadly mistake of using hashmap unsynchronized over the years. It’s also been a tricky one to debug once you’re hit with it as nothing really happens other than the one thread executing the hashmap code going into an infinite loop whilst still remaining in a RUNNABLE state and not a BLOCKED state which is what people tend to look for in thread dumps. The application may become unresponsive which may lead you to think that it’s probably just some slow code if you’re working with cpu intensive code like aggregate statistical calculations.

The key to effective debugging of such subtle concurrency bugs is to always have jvisualvm open on local processes and to check the real time thread visualisation tab frequently to see what your application is doing or if running live then to take multiple thread dumps either manually or programmatically and check for differences between them.

The second fix also made me laugh as this is another issue, though less critical than the previous one, has caused much inconvenience to both java developers, system administrators and support staff over the years. Large log files have resulted in periodic process restarts being incorporated and numerous emails being sent about running out of disk space. Can you believe that in this day and age we still run out of disk space? Much bash code has also been written to do log rotation manually as was the case in my last workplace and processing or reading large log files is also much slower.

Though, to be honest, I have to confess I’m a little confused by the Oracle bug system. On the second bug above it says ‘Closed, Will not Fix’ but at the same time under ‘Evaluation’ it says three new flags have been introduced so has the issue been fixed or not? I also noticed another bug which looked interesting: bug 7071826 – UUID.randomUUID() race condition. ID generation is a very critical function of any environment and if there was a race condition it could potentially be a serious and widespread issue but I noticed that in that bug there was no description of the problem; merely pointers to comments elsewhere but where? Where are those comments being held? Help me out if you know.

On a related note JDK7u6 introduces JDK and JRE support for Mac OS X!

5 thoughts on “Two bug fixes in JDK6u34 worthy of note

  1. Dhruba Bandopadhyay Post author

    Welcome Guang Sheng! Great to hear from you! Yes. When I wrote this post I was definitely thinking of my last position. We were hit by both issues in the last year and put workarounds in place. We were also using UUID quite a lot, though not the JDK one, so we wouldn’t be vulnerable to any race conditions in the jdk. I’m glad you guys found my post and I certainly hope it helped. That’s why I write – to help others and add value on the web.

  2. Dhruba Bandopadhyay Post author

    Life is good Guang Sheng. I’ve had a break which has been so good for me in so many ways. I really recommend that everyone try it at some point! Sometimes we don’t realise how much of a toll the rat race takes on us both in terms of mind and body. Hope all is well at your end.

  3. Guang Sheng

    Glad to know you are good! Life is about the same in Singapore, probably I need a small “comma” in my journey as well. Hope one day we have the chance to meet in real person! Wish you all well!


Leave a Reply