At 03:55 PM 10/22/2001, Boehm, Hans wrote:
> > -----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.
This expresses my point of view perfectly.
> >
> > 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
-------------------------------
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