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.
> >
> > 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?
Priorities are not ignored when scheduling occurs, but there is no preemption.
> 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? \
The Oracle VM is designed with the assumption that client will be
relatively short, but it does not constrain individual calls. The Oracle
VM is designed to run within the Oracle Database which is itself time
slicing between sessions. Each session gets its own VM and which is, as I
said, single threaded. The VM is running as part of a database session
which may be doing SQL and Java.
>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.
If you have some long computation you want to do (which might easily
involve both Java and SQL) you simply start it in one session and do other
things in another session which you wait for the first session to complete.
The situation here is similar to that of EJB's. There is a rule that an EJB
can't create threads. What you need to do if you want to have simultaneous
computations going on is create multiple beans. In the Oracle model of the
world each EJB would get its own VM.
>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