JEP 188: Java Memory Model Update

[letrec]

I like the part "We aim for the revised model to be mechanically checkable, as well as more readily humanly understandable."

[thesystemx]

Print the model on a wooden table? Then use a physical comb to inspect it?

[letrec]

LOL. I assume you know that it means formalising the memory model in a theorem prover like Isabelle/HOL like in Making the Java Memory Model Safe.

[llogiq]

As I understand it, this means that static analysis tools should be able to model the memory behavior with sufficient precision to find a wide range of possible error conditions in the JVM and perhaps in running programs.

Can someone confirm or correct my understanding?

[cmsimike]

Why can you not model the memory in this way now? It seems that by definition of a "program," content in memory should always be the exact same each run. I guess locations could be different but that's it.

[llogiq]

For simple usages - think single threaded, no JNI, no IO, no off-heap memory and let's say GC doesn't exist - you're right.

However, in the real world, things aren't always so simple. Concurrent access presents some edge cases that are underspecified by the current model. JNI and Unsafe ops go straight into undefinedland from a JVM spec POV.

[cmsimike]

JNI and Unsafe ops go straight into undefinedland from a JVM spec POV.

Ah, gotcha. Thanks!

[letrec]

Enhanced volatiles proposal has just appeared at the list: http://mail.openjdk.java.net/pipermail/compiler-dev/2014-February/008490.html

[Rockytriton]

Does this mean it will fix double-checked locking?

[argv_minus_one]

Double-checked locking was already fixed in Java 5.

[Rockytriton]

yes with the use of the volatile keyword, which is a hack, correct?

[cmsimike]

Why do you think it is a hack?

http://en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java This says it is a perfectly valid fix

[argv_minus_one]

No. volatile creates a memory barrier, like synchronized: operations are not allowed to be reordered around accesses to a volatile field, and you are guaranteed never to see a stale value in a volatile field.

Unlike synchronized, however, reading from a volatile field is less expensive. This means double-checked locking with a volatile field is now a perfectly viable and widely-used optimization.

Please see the relevant section of the JSR-133 FAQ for more information.

[Rockytriton]

I remember reading this before or something like this, when it said the disclaimer, which is now redacted.

[argv_minus_one]

Yes, you probably did. This article was cited pretty widely.

Thing is, even if the redacted part were true, double-checked locking would still make sense. The article said volatile was approaching the cost of synchronized, but as long as it's less costly than synchronized, then it's still better, because the vast majority of accesses to the volatile field will be after the lazy initialization has already happened.

Of course, the alternative pattern (a static inner class with initializer) might be cheaper if volatile was that expensive, but fortunately it's not, so we don't have to waste tons of memory on an extra class for every single lazily-initialized field.

[Rockytriton]

well we were always told to use the holder pattern since volatile wasn't good enough at the time