> -----Original Message-----
> From: Bill Pugh [mailto:pugh@cs.umd.edu]
> >
> >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).
>
> 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.
I would look at the issue differently:
Volatile reads can only be hoisted out of loops if doing so is not
observable. This can happen for example if the JVM can prove that the
variable is never concurrently written. That may happen if the code writing
it can provable never be executed. And that might happen because we have a
scheduler that never preempts a running thread. It's not at all clear to me
that the semantics needs to talk about any of this; hoisting the volatile
was legal only because it was invisible. I think this needs to be reflected
in the semantics only in that runnable threads are not guaranteed to make
progress, at least not if there is another runnable thread.
>
> 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.
>
Does the Oracle VM really behave this way? Priorities are ignored? Old Sun
VMs were a little different. If there were no higher priority threads,
"while (true);" would effectively stop the VM. But the VM could be made to
time-slice by adding a high priority thread running "while(true)
{Thread.sleep(100);}", which would force regular scheduling decisions. Last
I tried, some browser VMs still behaved that way.
My understanding is that the Oracle VM normally expects Java code to
terminate quickly anyway? If you don't have long running compute-bound
threads, probably none of this is very important, and it makes sense not to
bother with preemption. Otherwise I think it's very hard to program without
it.
Hans
-------------------------------
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