I agree that this should be discussed explicitly, and hasn't been discussed sufficiently.
My impression is that the precise exception model should be preserved for synchronous exceptions,
and it never really existed for asynchronous ones. If everyone agrees with that, we're arguably
done, though perhaps the JLS should really state that only synchronous exceptions are precise.
According to 11.1, there are two possible causes of asynchronous exceptions:
1) Thread.stop().
2) An internal VM error.
Realistically, I suspect there is very little you can guarantee for (2) in any case.
It reports that the VM did something detectably wrong. I suspect that detectable
errors are often preceded by undetectable ones anyway. Writing the spec to restrict
the nature of JVM bugs and hardware failures seems pointless, especially if that
restricts optimizations.
The Thread.stop() procedure is deprecated because it's essentially broken, as discussed
in the documentation. It seems its still there because some software (which probably
works correctly most, but not all of the time) still uses it. Thus VM implementors
should maybe, possibly (*) be encouraged to implement it on a best effort basis, and users should
certainly continue to be discouraged from using it. For some VMs it would have
disastrous optimization consequences if Thread.stop() exceptions were actually precise.
I do not think that Thread.stop() should be mentioned in the memory model at all.
It's semantics should be left as unspecified as possible.
Hans
(*) I'm actually not at all sure that Thread.stop() shouldn't just be killed completely.
Its existence means that if you have a pointer to a thread updating a data
structure, you can almost certainly force that thread to leave the data structure in
a fairly arbitrary corrupted state. That includes private system data structures that you shouldn't
know about. Hence I think there's really no guarantee that system libraries work
as expected after such a call. What are the security implications of that?
-----Original Message-----
From: owner-javamemorymodel@cs.umd.edu [mailto:owner-javamemorymodel@cs.umd.edu]On Behalf Of Vijay Saraswat
Sent: Thursday, April 08, 2004 6:44 AM
To: javamemorymodel-cs.umd.edu
Subject: JavaMemoryModel: Interaction between the memory model and exceptions
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