Page History

*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§14.4), formal method parameters (§8§8.4.1) or exception handler parameters are never shared between threads and are unaffected by the memory model \[[JLS 2005|AA. References#JLS 05]\]. 

*hide* One class field hides a field in a superclass if they have the same identifier. The hidden field is not accessible from the class. Likewise, a class method hides a method in a superclass if they have the same identifier but incompatible signatures. The hidden method is not accessible from the class. See \[[JLS 2005|AA. References#JLS 05]\] [§8§8.4.8.2|http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.4.8.2] for the formal definition.  Contrast with [override|BB. Glossary#override].

*obscure* One scoped identifier obscures another identifier in a containing scope if the two identifiers are the same, but the obscuring identifier does not [shadow|BB. Glossary#shadow] the obscured identifier. This can happen when the obscuring identifier is a variable while the obscured identifier is a type, for example. See \[[JLS 2005|AA. References#JLS 05]\] [§6§6.3.2|http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.3.2] for more information.

*override* One class method overrides a method in a superclass if they have compatible signatures. The overridden method is still accessible from the class via the {{super}} keyword. See \[[JLS 2005|AA. References#JLS 05]\] [§8§8.4.8.1|http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.4.8.1] for the formal definition. Contrast with [hide|BB. Glossary#hide].

*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§17.4.3)" \[[JLS 2005|AA. References#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. References#JLS 05]\].

*shadow* One scoped identifier shadows another identifier in a containing scope if the two identifiers are the same and they both reference variables. They may also both reference methods or types. The shadowed identifier is not accessible in the scope of the shadowing identifier. See \[[JLS 2005|AA. References#JLS 05]\] [§6§6.3.1|http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.3.1] for more information. Contrast with [obscure|BB. Glossary#obscure].

*volatile* "A write to a volatile field (§8§8.3.1.4) happens-before every subsequent read of that field" \[[JLS 2005|AA. References#JLS 05]\]. "Operations on the master copies of volatile variables on behalf of a thread are performed by the main memory in exactly the order that the thread requested" \[[JVMSpec 1999|AA. References#JVMSpec 99]\]. Accesses to a volatile variable are [sequentially consistent|BB. Glossary#sequential consistency] which also means that the operations are exempt from compiler optimizations. Declaring a variable volatile ensures that all threads see the most up-to-date value of the variable if any thread modifies it. Volatile guarantees atomic reads and writes of primitive values; however, it does not guarantee the atomicity of composite operations such as variable incrementation (read-modify-write sequence).