The fact that it calls a method which contains a barrier ... is irreverent.
Ah, if only that misprint was what you meant!
"Damn, fool, don't you be dissing me by calling no methods"
If my reading is incorrect that means that java is very limited in the set of transformation that it can apply because it must "prove" that no called function contains a load-fence/store-fence or full barrier.
If it first inlined the method call(s), surely that wouldn't be that difficult? btw - even if this was single threaded, it would have to prove that no method call changed the inlined value!
Even if my reading is incorrect the variable still should be defined volatile so the code's intent is clear both to the compiler and anyone reading the code in the future (including the author at some point in the future).
Absolutely! In fact, as I said earlier I reckon the bug at the start of this thread is probably due to improperly paired lock calls, which would explain the simpler test case working OK, and a good reason for making intent clear.
The JVM bug linked to earlier, or rather the thread about it, does highlight that there aren't (weren't?) good test cases for the memory model in code output by the JIT compiler. Another reason not to trust edges cases in the JMM too much!