While at TSSJS Barcelona, Cliff Click from Azul systems spoke with Kirk Pepperdine about his work at Azul, his involvement with the -server compiler team, and a whole host of hardware issues as they relate to the Java memory model, thread safety, and program correctness. When asked what it meant for the compiler to "hoist" a variable, Cliff responded with an in depth explanation of the technique as well as its implications on correctness.

"Even though the program textually looks like I read that variable over and over again, in practice I don't. I'm going to read it once and I'm going to leave it in the register and I'm going to do all of my modifications and work on it in the register computing the same value I would as if I'd written it down to memory and then loaded it back up into memory."

The discussion touched on a number of points about the under-pinnings of Java and features that the execution stack must have in order to support true multi-threaded applications. Cliff explains how the different hardware memory models work to protect us against discovering data race bugs in our applications. He provides an in depth analysis of double check locking. The talk winds down with a small discussion of things that Cliff believes would be helpful in our future efforts to produce bug free multi-threaded code. Download the podcast and read the full interview transcript here

Cliff is one of the brightest engineers I have had the pleasure of meeting and working with .. beyond doubt, when it comes to software and technology, he is worth listening to. Peace, Cameron Purdy Oracle Coherence: The Java Data Grid

As well as being very bright he is also extremely amiable - especially when discussing contentious performance observations and/or opinions. Cliff was more than willing to share his time when he could have easily followed the example of others and lazily rebuffed an observation without first attempting to understand the wider context. I was pleasantly surprised with the level of attention he afforded questions we made. This is a very good interview with Kirk that contains much more information than one expects. regards, William

Here is the link for Cliff's talk at Google Tech Talks on Lock-Free Hash Table. http://video.google.com/videoplay?docid=2139967204534450862 He is simply amazing...

Listened to it yesterday and it was excellent. Too bad a lot of it is over my head.

Listened to it yesterday and it was excellent. Too bad a lot of it is over my head.

+1 Here is some additional Java Memory Model stuff: http://gee.cs.oswego.edu/dl/jmm/cookbook.html

Listened to it yesterday and it was excellent. Too bad a lot of it is over my head.

I'd appreciate knowing where things got a bit steep. Kind regards, Kirk

Listened to it yesterday and it was excellent. Too bad a lot of it is over my head.

I'd appreciate knowing where things got a bit steep.

For me, this was not easiest part: "Cliff Click: Yeah. So, atomics are another, are, well, atomics are Java’s way of getting at the CAS instruction, which is, stands for Compare-And-Swap, it’s the unit atomic update on all modern platforms. PowerPC does something called load-link-store-conditional, it’s very similar, the differences are very minor, but basically it means that you can do a read-modify-write cycle atomically. And that’s the key bit that we will build all of the synchronization primitives out , not just the synchronized keyword, VMs have internal locking that’s built on top of these but also the java.util.concurrent utilities have you know the Doug Lea Lock – capital L – Lock structures, the re-enterant Lock, the read-and-write-Lock, and all those locks are all built on CAS instructions as well. So, under the hood, they use the CAS instruction. And that’s what atomic is, it gives you direct access to CAS instruction." Anybody out there uses volatile to fix the double checked locking?

Anybody out there uses volatile to fix the double checked locking?

There is a better way, which works in JVMs before the new memory model as well, - Pughs singleton holder.

Anybody out there uses volatile to fix the double checked locking?

There is a better way, which works in JVMs before the new memory model as well, - Pughs singleton holder.

Any references?

Anybody out there uses volatile to fix the double checked locking?

There is a better way, which works in JVMs before the new memory model as well, - Pughs singleton holder.

Any references?

For instance http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html search for "Initialization On Demand Holder". Some more explanation (Goetz): http://www-128.ibm.com/developerworks/java/library/j-jtp03304/.

For instance http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html search for "Initialization On Demand Holder".

Thanks. Static initializer would be an easier name. Which pattern is used by Spring to create Singletons?

For instance http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html search for "Initialization On Demand Holder".

Thanks. Static initializer would be an easier name.

Which pattern is used by Spring to create Singletons?

Static inializer would be too general. The neat trick with the holder is that it defers creation of the singleton instance untill someone calls "getInstance". If the instance is just created in a static initializer then it would be created when the singleton class is loaded.

For instance http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html search for "Initialization On Demand Holder".

Thanks. Static initializer would be an easier name.

Which pattern is used by Spring to create Singletons?

Static inializer would be too general.

The neat trick with the holder is that it defers creation of the singleton instance untill someone calls "getInstance". If the instance is just created in a static initializer then it would be created when the singleton class is loaded.

Yor are right.

Aren't the two following code snippets exactly equivelent in terms of when the instantiation of Something occurs? public static Something something = new Something(); public static Something something; static{ something = new Something(); } My understanding is that for both the instantiation will occur the first time any kind of reference is made to the class containing these static declarations e.g. Class.forName("ContainingClass"). Is this not correct?

{...} Is this not correct?

Check this:private static class LazySomethingHolder {    public static Something something = new Something(); }public static Something getInstance() {    return LazySomethingHolder.something; }

Aren't the two following code snippets exactly equivelent in terms of when the instantiation of Something occurs?


public static Something something = new Something();



public static Something something;
static{
something = new Something();
}

Yes, those two are identical. Peace, Cameron Purdy Oracle Coherence: The Java Data Grid

Anybody out there uses volatile to fix the double checked locking?

There is a better way, which works in JVMs before the new memory model as well, - Pughs singleton holder.

Any references?

For instance http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html search for "Initialization On Demand Holder".

Some more explanation (Goetz): http://www-128.ibm.com/developerworks/java/library/j-jtp03304/.

Was it Pugh that invented this idiom? I thought it was Lea - at least, it's in his (now very old) Concurrent Programming in Java, first edition. Anyways, I've only seen the Lock-Free Hashtable talk by Clif Click on Google, but I was very, very impressed. Particularly at his thoughtful answers to questions.

Listened to it yesterday and it was excellent. Too bad a lot of it is over my head.

I'd appreciate knowing where things got a bit steep. Kind regards,
Kirk

The locking bits was a bit hard for me to get, but that's my own limitation. The explanations were good, I just lack the depth to really understand the subtleties and know where and how locking becomes difficult. peter