I wrote:
> All exceptions are required to be precise according to the JLS.
JLS 11.3.1 says:
"Exceptions are precise: when the transfer of control takes place, all
effects of the statements executed and expressions evaluated before the
point from which the exception is thrown must appear to have taken place. No
expressions, statements, or parts thereof that occur after the point from
which the exception is thrown may appear to have been evaluated. If
optimized code has speculatively executed some of the expressions or
statements which follow the point at which the exception occurs, such code
must be prepared to hide this speculative execution from the user-visible
state of the program."
So this seems to require ordering at the source-level to be honoured. That
would seem to place a potentially greater burden on the VM.
For synchronous exceptions the requirements seem quite straight-forward: if
you optimise across an explicit throw or statement that may throw an
exception, then you have to fix things up when throwing the exception. In
that sense throw points act as potential code motion barriers (yes all those
bad words again). If the system can determine an exception can't happen (not
null, checkcast will succeed, in bounds access etc) then it can optimise
across the throw point. I'm not aware of any way to undo writes that become
visible, so my guess is the only option is not to reorder things in such
situations.
It seems to me that the JMM must say something about this, if only to
restate the implications of 11.3.1 in a clear way.
Asynchronous exceptions are slightly harder. Ignoring how they can occur for
a moment, they too must be precise. But to allow for maintaining the precise
nature of async exceptions there is a bounded amount of time permited
between the exception occuring and it being thrown (11.3.2).
What makes async exceptions worse is that now any bytecode is potentially a
throw point. So again, given there is no way to undo a write that became
visible (even if the write was not guaranteed to become visible) the only
option sees to be to preserve that actual program order. So a JVM that
allows async exceptions to truly occur anywhere would seems to have very
limited scope for any kind of reordering.
However, if you poll for async exceptions as suggested by the JLS then the
VM has much more control and simply wouldn't process the async exception at
a bad place - such as between assignment statements. Hence the JVM can
perform optimisations as before, as long as they don't cross the poll
points. This works fine for async exceptions caused by Thread.stop, or in
the RTSJ for AsynchronouslyInterruptibleException.
Async exceptions caused by internal VM errors seem more problematic as these
literally appear to occur "inside" the execution of a bytecode. And given
the VM doesn't really expect them to happen, catering for their memory
semantics seems rather ambitious. My feeling is that in practice the
internal error is of far more concern than the imprecise nature of the
exception.
Bottom line is that I think the JMM needs to discuss these issues.
David Holmes
-------------------------------
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