Java Concurrency (&c)

While I'm posting anyway, I might as well mention the big concurrency news of the day: the new transactional memory specification from Intel. Transactional memory sounds a lot like what it is. Your code begins a transaction and continues to execute it until it ends, performing some memory writes along the way. If there are no conflicting transactions (i.e., transactions that write to the same memory that your code wrote) executing at the same time as yours, your transaction will end normally and commit your memory writes. If there are conflicting transactions, your transaction will abort and roll back your writes. Transactional memory on x86 will come in two flavors: Hardware Lock Elision (HLE), which consists of XACQUIRE and XRELEASE instruction prefixes. These can optimistically turn lock regions into transactions. What's the advantage? Well, transactions can execute concurrently, as long as they aren't writing to the same memory. Locks are serialized: only one ...

A couple of years ago, I open-sourced a tool that lets you instrument all of the allocations in your Java program . Some quick updates today: It now supports JDK7. You can now optionally use it to instrument constructors of a particular type, instead of allocations. So, if you wanted to find out where your Thread s were being instantiated, you could instrument them with a callback that invokes Thread.dumpStack(). I know that most of the readers of this blog are more interested in concurrency, and that it has been a very, very long time since I posted. The spirit is willing, but the flesh is insanely busy... I have it in mind to do a post that discusses a bunch of strategies for doing efficient non-blocking concurrency in C++, because the attempts are very amusing, but I haven't had the chance to sit down and do it.

I should probably comment on this paper from my colleague Robert Hundt , where he writes the same benchmark in Java, Scala, Go, Python and C++ ( TL;DR here ). Short version: Initially, C++ was faster than Scala, and Scala was faster than Java. I volunteered to make some improvements, which ended up with the C++ and Java implementations being about the same speed. Some C++ hackers then went and improved the C++ benchmark by another ~6x, and I didn't think I should go down that road. Imagine my surprise when I got this email from a friend of mine this morning: Date: Fri, 3 Jun 2011 03:20:48 -0700 Subject: Java Tunings To: Jeremy "Note that Jeremy deliberately refused to optimize the code further, many of the C++ optimizations would apply to the Java version as well." Slacker. Gee, thanks for making me look good, Robert. (Actually, I had approved that language, but I didn't realize anyone would actually read the paper. :) ) Anyway, I was not just being obdurate here;...

Josh Bloch and I gave one of his Java Puzzlers talk at Google I/O this year. If you hate Java, you can waste a perfectly good hour listening to us make unfunny jokes at its expense.

Cliff Click gave a very good talk at Google last week. For your viewing enjoyment: The slides are available here . (For those who watched it: The inventors of bytecode were in the audience. I think he was just used to making that joke elsewhere.)

Because I am a Google employee, my talks are not happening . Apologies to any interested parties. I'm going to try to give the talks in another venue, or at least to use the blog as a venue for some of the topics I wanted to cover.

This is a followon to a blog post I made in 2007 about using signal handling to profile Java apps . I mentioned in another post why this might be a good idea , but I wanted to expand on the theme. Hiroshi Yamauchi and I are giving a talk at this year's JavaOne . Part of this talk will be about our experiences writing profilers at Google, and in preparing for it, I realized my previous entry on this subject only told half the story. The topic of the original post is that there is an undocumented JVMTI call in OpenJDK that allows you to get a stack trace from a running thread, regardless of the state of that thread. In Unix-like systems, you can use a SIGPROF signal to call this function at (semi-)regular intervals, without having to do anything to your code. The followon post, intended to describe why you would use this, described a couple of things that are true: That it tells you what is actually running on your CPU, not just what might be scheduled, which is what profilers ...