<$BlogRSDUrl$> function setAttributeOnload(object, attribute, val) { if(window.addEventListener) { window.addEventListener('load', function(){ object[attribute] = val; }, false); } else { window.attachEvent('onload', function(){ object[attribute] = val; }); } }
Wednesday, April 21, 2004
Fixing the Java Memory Model, Part 1

Memory model describes the relationship between variables in a program (instance fields, static fields, and array elements) and the low-level details of storing them to and retrieving them from memory in a real computer system. Objects are ultimately stored in memory, but the compiler, runtime, processor, or cache may take some liberties with the timing of moving values to or from a variable's assigned memory location.

The JMM allows the compiler and cache to take significant liberties with the order in which data is moved between a processor-specific cache (or register) and main memory, unless the programmer has explicitly asked for certain visibility guarantees using synchronized or volatile. This means that in the absence of synchronization, memory operations can appear to happen in different orders from the perspective of different threads.

By contrast, languages like C and C++ do not have explicit memory models -- C programs instead inherit the memory model of the processor executing the program. Program may fail on a different processor architecture. While the JMM may be confusing at first, there is a significant benefit to it -- a program that is correctly synchronized according to the JMM should run correctly on any Java-enabled platform.




Comments: Post a Comment

This page is powered by Blogger. Isn't yours?