At 02:58 PM 10/22/2001, Bill Pugh wrote:
>>In terms of my earlier email on modelling semantics (to which no one ever
>>responded), the semantics of thread 2 require repeated memory operations
>>(reads) of Volatile1 until a read returns a value not equal to 1. The
>>system is free to avoid those reads when it can determine that doing so
>>will not violate the semantics of the overall program. For example, a
>>compiler that knew it was acting in the context of a non-preemptive
>>scheduler would be free to hoist the read in Thread 2. But a compiler
>>that is acting without context (such as a java to bytecode compiler) is
>>not free to make that transformation.
>
>
>Java should only have one semantics, not two (a preemptively scheduled
>semantics and a non-preemptively scheduled semantics).
I agree with the conclusion that we shouldn't have a preemptively scheduled
semantics that is different from a non-preemptively scheduled semantics,
and I don't think what I said contradicts it.
I believe, however, that to give a semantics to Java we need to give it in
two stages. First a semantics to threads that involves memory operations.
And then a semantics to Java that is based on the semantics of threads, but
in which the meaning of Java programs does not include memory operations.
>If we decide that reads of volatiles can be hoisted out of infinite loops,
>then we should allow them to be hoisted out of infinite loops on all
>platforms, not just Oracle's. And if we allow Oracle's compiler to do it,
>then any bytecode transformation that does it should be legal for all Java
>platforms.
Hoisting is not an operation that the semantics is concerned with.
I hope no one will disagree that the semantics of a thread
Volatile1 = 0;
while (Volatile1 != 1) {;}
print "Success"
is pretty clearly that the thread will write to Volatile1 and then
repeatedly read Volatile1 until a value equal to 1 is read and then it will
print "Success".
The semantics of a program in which this is the only thread is to loop
forever. It is not even meaningful to ask whether the program is reading or
writing Volatile1 since memory operations are not part of the meaning of a
program.
Suppose the program has many threads but none of the other threads will
read or write Volatile1. The system might notice that the meaning of the
program in unchanged by replacing the code implementing this thread by code
that just loops forever (i.e. by "hoisting the read"). In that case it
could make that replacement based on its freedom to generate any code it
likes provided it implements the semantics of Java. We do not need to
adjust the thread semantics in order to allow that transformation.
>I understand that the issue is a little bigger than I had spoken of
>earlier; putting fairness into Java semantics will prohibit any pure
>non-preemptive JVM (e.g., a VM in which "while (true);" halts the entire VM).
>
>I am willing to go either way on this. Allowing "while (true);" to halt
>the entire VM is rather unpleasant, but it may be too difficult to force
>all VM implementors to use some form of preemption.
Requiring fairness in any form would certainly be a major change and one
unrelated to the memory model.
> Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:35 EDT