> I'm worried that the change is even necessary.
>
> The original JMM in Chapter 17 of the JLS stated quite clearly that
> reading/writing volatiles always went to "main memory" hence such
> transformations were automatically disallowed.
>
> I'm worried, as I've stated in the past, that the new JMM's philosophy that
> the system "can do what it likes as long as it can't get caught", impacts on
> scheduling/fairness issues that should not be part of the JMM. This includes
> the examples of synchronized block merging, and moving accesses into
> synchronized blocks. I feel the new JMM is too biased toward the JVM, at the
> expense of a straight-forward programming model.
Except that this isn't really as much about optimizations as it is about
fairness. The original JMM's guarantee about volatiles going straight to
maing memory doesn't mean anything in this regard, because it didn't have
any fairness guarantees either. The same transformation I described could
probably be performed and not violate whatever specification exists.
The point is that (under chapter 17) even though volatile writes always go
to "main memory", and volatile reads always come directly from "main
memory", it is still the case that neither the write nor the read is
guaranteed to happen.
As an aside on volatiles, this is curiously the one thing where our spec and
the old spec mean exactly the same thing in a clear and convincing way.
Anyway, this change means that although these actions still aren't
guaranteed to happen, their not happening can't be achieved by way of a
source-to-bytecode transformation like the one I mentioned.
On the whole, we have avoided fairness issues; we have a section stating
they are quality-of-service. This is because there has been a relative
consensus that they are unwanted.
Jeremy
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:03 EDT