“volatile” – 3: Java

What java brought to the programming languages was extraordinary. Not that it was the first to implement it, it was the first implementing it in a way that revolutionized the way for other programming languages.

If we say java is only a programming language, it would be wrong. In fact it is a platform does many things an operating system does. User interface, security, executable discovery, file system and many more libraries are defined in itself. In that platform memory management and different programming languages are supported.

One can say that java has a machine language for itself, it won’t be wrong. But different from its predecessors, it started as an interpreting platform (anyways, what real hardware does is, in fact, interpreting the machine language, but in a much more faster way, nothing more), later advancements made it close to real machine execution (JIT itself is a miraculous invention).

From all these mumbo-jumbo, what java brings is better productivity and platform independency. Independency is copy paste independency not preprocessing helped recompilation. Take your code to another platform and voila! It will work.

This explanation may not come as an extraordinary invention to the contemporary engineers; it is a game changing establishment in the history of computer science.

From all of this, if original inventors of java have omitted some features in the mist of the revolution, this, i think, is not only forgivable, it is also a clear indication that humans are capable of doing such things, so also you can manage such implementation.

What it was like before

Now that we have said this, the original implementation of “volatile” in java is implemented in a way off [1] [2]. One would expect a volatile variable should behave as a memory barrier, but the first implementation did not provide this. What original implementation provided was only cache invalidation. Code reordering still was possible.

In fact, this was what java platform behaved like. Java was a bad boy when reordering for performance was needed. No matter what, it would have rearranged that [3] [4]. This is in fact is influenced from the optimizations for single threaded applications. Java first developed in a world of single threaded applications and in that time, it was mostly OK. But as the time passed, as the multithreaded applications surfaced, engineers started to find out oddities in the execution and later it become clear that even the famous double checking lock was not guaranteed in java in those days. Only synchronization that would definitely work was “synchronized” keyword. If you did that, it would work else do not even try. Whatever you would do, in some scenario it would fail.

What it has become

But everything changed in the last months of 2004 when the new java version of 2 (J2SE 5.0) came out [5]. “volatile” started to behave as it should be; A memory barrier and a cache invalidator.

Java is very keen on the backward compatibility. For example, when implementing generics, because of these concerns, generics did not become runtime templates but c style compile time templates [6]. Some intricacies of generics come from this fact and the famous “sometype<?>” notation owes its existence to this fact. “volatile” on the other hand is an exception that brakes this. It has been changed from one version to the other.

This is the story of volatile in Java, in a nutshell.

References

  1. Java theory and practice: Fixing the Java Memory Model, Part 1, http://www.ibm.com/developerworks/java/library/j-jtp02244/index.html
  2. Java theory and practice: Fixing the Java Memory Model, Part 2, http://www.ibm.com/developerworks/library/j-jtp03304/
  3. Double-checked locking: Clever, but broken, http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html
  4. Can double-checked locking be fixed?, http://www.javaworld.com/javaworld/jw-05-2001/jw-0525-double.html
  5. JSR 133: Java™ Memory Model and Thread Specification Revision, http://jcp.org/en/jsr/detail?id=133
  6. Learning Java Third Edition 2005 (O’Reilly) by Patrick Niemeyer & Jonathan Knudsen, Chapter 8: Generics, Sections: “There Is No Spoon”/Erasure.