What is the scope of cache flushing required by Java's synchronize keyword?

Question

I have been researching the Java Memory Model all day today, in order to understand in detail the problems with the JMM pre-Java 5 and the changes made by JSR-133 implemented in Java 5.

What I cannot seem to find a definitive answer on is the scope of cache invalidation and flushing required on a particular synchronize.

Must all CPU registers and caches be invalidated when entering any synchronized portion of code and all flushed to main RAM when leaving, or is the JVM allowed to only invalidate those variables actually read, and flush only those actually written during the synchronized block of code?

If the former, why is the JMM so pedantic about insisting the that memory barrier only occurs between two threads which synchronize on exactly the same object?

If the latter, is there any good document that explains the details of how this is accomplished? (I would suppose the underlying implementation would have to set a "bypass caches" flag at the CPU level at the start of a synchronized block and clear it at the end, but I could be way off base.)

Answer 1

There is very nice tech talk on Java Memory model . If you dislike wideos google 'happens before' in context of Java Memory Model.

Basically all writes are visible to other threads if there is happens before relationship, Lets assume thaat thread A writes to field X, and thread B reads from it, so happens before is establishend between write and read if:

• x is volatile
• write to x was in guarded by the same lock that read from x
• maybe some more.

So I think that the second option is true, how they implemented it, I dont know.

Answer 2

You need to understand that the pre-5.0 JMM was never really implemented exactly, because it wasn't actually feasible.

So pre-5.0 you did technically have to write everything out to shared memory. In 1.5 (actually 1.4) this is relaxed. In particular, if a lock cannot escape a thread, then the JVM is entitled to treat it as a nop. Further, an unlock followed by a lock of the same lock can be coalesced, which is not true of the old JMM. For an escaped lock, the JVM often has to be pessimistic and flush more than is technically necessary.

Answer 3

I'd suggest you start with:

• Doug Lea's "JSR-133 cookbook" which gives information for compiler writers on how to implement the memory model
• The Java Memory Model mailing list archive , where you can read through some of the arguments that were flying about that led to the current revision of the JMM.