java-memory-model

I know that the JVM memory model is made for lowest common denominator of CPUs, so it has to assume the weakest possible model of a cpu on which the JVM can run (eg ARM). Now, considering that x64 has a fairly strong memory model, what synchronization practices can I ignore assuming I know my program will only run on 64bit x86 CPUs? Also does this apply when my program is being run through virtualization? Example: It is known that JVM's memory model requires synchronizing read/writes access to longs and doubles but one can assume that read/writes of other 32 bit primitives like int, float etc

This question already has an answer here: How to understand happens-before consistent 4 answers I'm trying to understand Java happens-before order concept and there are a few things that seem very confusing. As far as I can tell, happens before is just an order on the set of actions and does not provide any guarantees about real-time execution order. Actually (emphasize mine): It should be noted that the presence of a happens-before relationship between two actions does not necessarily imply that they have to take place in that order in an implementation. If the reordering produces results

This question is in reference to memory visibility only, not happens-before and happens-after. There are four ways in Java that guarantees changes to memory in one thread to be made visible to another thread. (reference http://gee.cs.oswego.edu/dl/cpj/jmm.html ) A writing thread releases a synchronization lock and a reading thread subsequently acquires that same synchronization lock. If a field is declared as volatile, any value written to it is flushed and made visible by the writer thread before the writer thread performs any further memory operation (i.e., for the purposes at hand it is

I read from Effective Java that In the absence of synchronization the following sequence A below can be converted into sequence B by the virtual machine and this is called hoisting . I also read somewhere that if variables are not declared as volatile instructions involving the variables can be reordered . Are hoisting and reordering the same thing? while (!done) sequence A i++; if (!done) while (true) sequence B i++; They are slightly different. Hoisting means that you have pulled some operation out of a loop because the loop itself does not affect the result of the operation. In your case,

The code below (Java Concurrency in Practice listing 16.3) is not thread safe for obvious reasons: public class UnsafeLazyInitialization { private static Resource resource; public static Resource getInstance() { if (resource == null) resource = new Resource(); // unsafe publication return resource; } } However, a few pages later, in section 16.3, they state: UnsafeLazyInitialization is actually safe if Resource is immutable. I don't understand that statement: If Resource is immutable, any thread observing the resource variable will either see it null or fully constructed (thanks to the strong

JSR-133 FAQ says: But there is more to synchronization than mutual exclusion. Synchronization ensures that memory writes by a thread before or during a synchronized block are made visible in a predictable manner to other threads which synchronize on the same monitor. After we exit a synchronized block, we release the monitor, which has the effect of flushing the cache to main memory, so that writes made by this thread can be visible to other threads. Before we can enter a synchronized block, we acquire the monitor, which has the effect of invalidating the local processor cache so that

This question already has an answer here: How to understand happens-before consistent 4 answers In the book Java Concurrency In Practice, we are told several time that the instructions of our program can be reordered, either by the compiler, by the JVM at runtime, or even by the processor. So we should assume that the executed program will not have its instructions executed in exactly the same order than what we specified in the source code. However, the last chapter discussing Java Memory Model provides a listing of happens-before rules indicating which instruction ordering are preserved by