Discussions on Java memory model

[Jeff Sturm]

Miles Sabin wrote:
> It's also worth bearing in mind that these aren't just issues
> for SMP machines ... some of the problems show up on 
> uniprocessors too because you don't necessarily have 
> particularly strong guarantees about write ordering.

Yup.  They gave an example: the Symantec JIT for x86 in some cases will
inline the constructor and reorder the writes such that it fails the
double-check idiom, even on a uniprocessor.

Although gcj doesn't inline constructors (yet), the warning still
applies for any shared-memory multiprocessors which are free to reorder
loads/stores (e.g. Alpha, ia64?).

> This is a pretty big deal, because there's a range of 
> concurrent programming idioms (double-check, array copy on 
> write) that simply can't be guaranteed to work in the way you'd 
> expect under the current JMM.

Loosely stated, the rule is "synchronize access to all shared variables
to be safe".  Unfortunately that is both inefficient and non-intuitive.

Getting the semantics tightened for final and volatile will help. 
Currently gcj doesn't appear to generate any special code for either (is
there even such a thing as a RTL pattern for memory barrier?)

--
Jeff Sturm
jeff.sturm@appnet.com