Page History

*happens-before order* Two actions can be ordered by a happens-before relationship. If one action happens-before another, then the first is visible to and ordered before the second. \[...\] 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 consistent with a legal execution, it is not illegal. \[...\] More specifically, if two actions share a happens-before relationship, they do not necessarily have to appear to have happened in that order to any code with which they do not share a happens-before relationship. Writes in one thread that are in a data race with reads in another thread may, for example, appear to occur out of order to those reads \[[JLS 2005|AA. Bibliography#JLS 05]\]. 

*heap memory* Memory that can be shared between threads is called shared memory or heap memory. All instance fields, static fields and array elements are stored in heap memory.\[ ...\] Local variables (§14.4), formal method parameters (§8.4.1) or exception handler parameters are never shared between threads and are unaffected by the memory model \[[JLS 2005|AA. Bibliography#JLS 05]\]. 

It is technically possible to have an immutable object without all fields being final. {{String}} is such a class but this relies on delicate reasoning about benign data races that requires a deep understanding of the Java Memory Model. (For the curious: {{String}} lazily computes the hash code the first time {{hashCode}} is called and caches it in a nonfinal field, but this works only because that field can take on only one nondefault value that is the same every time it is computed because it is derived deterministically from immutable state.) \[[Goetz 2006|AA. Bibliography#Goetz 06]\].

*obsolete reference* An obsolete reference is simply a reference
that will never be dereferenced again \[[Bloch 2008|AA. Bibliography#Bloch 08]\].

*sequential consistency* "Sequential consistency is a very strong guarantee that is made about visibility and ordering in an execution of a program. Within a sequentially consistent execution, there is a total order over all individual actions (such as reads and writes) which is consistent with the order of the program, and each individual action is atomic and is immediately visible to every thread. \[...\] If a program is correctly synchronized, all executions of the program will appear to be sequentially consistent (§17.4.3)" \[[JLS 2005|AA. Bibliography#JLS 05]\]. Sequential consistency implies there will be no compiler optimizations in the statements of the action. Adopting sequential consistency as the memory model and disallowing other primitives can be overly restrictive because under this condition, the compiler is not allowed to make optimizations and reorder code \[[JLS 2005|AA. Bibliography#JLS 05]\].