This pretty much falls out of the rules for unithread semantics.
Exceptions aren't really treated
any different from any other form of control flow.
But we could put in some statements about it.
The only thing which is a little tricky here are asynchronous
exceptions, such as
ThreadDeath and OutOfMemory. Are those exceptions required to be
precise?
The Real-time Java people have probably looked at this in more detail.
Bill
On Apr 8, 2004, at 9:43 AM, Vijay Saraswat wrote:
> Sorry if this has already come up and I have missed this...(this
> issue came up in a different discussion related to Java extensions and
> I thought I would check on this list for what stance is being taken by
> JSR 133).
>
> (Please note that this message is not about the "Unified Model" -- it
> is about what the Java Memory Model should be.)
>
> The Java Memory Model conceptually deals with the specification of
> out-of-order execution and conditional execution.
>
> How does this interact with the Java requirement for precise
> exception handling?
>
> =============================================================
> http://java.sun.com/docs/books/jls/second_edition/html/
> exceptions.doc.html#44044
>
>
> 11.3.1 Exceptions are Precise
> 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.
> ==============================================================
>
> Clearly, some issues are not problematic. For instance, the JMM
> ultimately describes simply the values returned by Memory to a read
> request from a thread. For properly initialized programs, this should
> not cause any exceptions in itself. Once this value is received at the
> thread, processing of this value may cause an exception (e.g. null
> pointer exception) which will be raised by the thread in its normal
> processing.
>
> However, a central question that is not so easy to answer (because it
> interacts fundamentally with the concurrency/memory consistency model)
> is: what heap state is any exception handler guaranteed to see? For
> instance, is it guranteed that all instructions (including reads and
> writes) issued by this thread that should have happened-before the
> instruction that threw the exception actually executed? 11.3.1 quoted
> above says "yes". Is this what makes sense?
>
> Further, can a Thread i see the result of an "out of order" write
> that may have been done by Thread j ... but it so happened that Thread
> j threw an exception when processing an instruction that
> happens-before that write? 11.3.1 says no. Is this what makes sense?
>
> I quickly scanned the JSR 133 draft but there appears to be no
> discussion of this issue.
>
> This seems like a major omission to me and there should be an
> explicit discussion. Even if the discussion just reaffirms the
> "precise exceptions" doctrine.
>
> Also, there should be several test cases in the standard suite that
> illustrate the issues with the interaction between the memory model
> and precise exception generation.
>
> Best,
> Vijay
>
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:02 EDT