According to the current API spec for OutOfMemoryError:
"Thrown when the Java Virtual Machine cannot allocate an object because it is
out of memory, and no more memory could be made available by the garbage collector."
I think that makes it synchronous.
StackOverflowError is more of an issue. But I would guess that most implementations
that try to throw this error reliably will do so synchronously at method entry.
I think ThreadDeath is irrelevant. (Oddly enough, ThreadDeath is not marked
deprecated even though Thread.stop() is. But ThreadDeath without Thread.stop()
is harmless.)
According to the current spec, all exceptions are precise. I'd be more comfortable
if that were clearly limited to synchronous exceptions, since I don't believe that
current JVMs implement precise asynchronous exceptions anyway. But I don't know
if we can do anything about it at this stage. And we would have to be a bit more
precise about which exceptions are synchronous.
Hans
-----Original Message-----
From: owner-javamemorymodel@cs.umd.edu [mailto:owner-javamemorymodel@cs.umd.edu]On Behalf Of Bill Pugh
Sent: Friday, April 09, 2004 6:16 AM
To: Vijay Saraswat
Cc: javamemorymodel-cs.umd.edu
Subject: Re: JavaMemoryModel: Interaction between the memory model and exceptions
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:03 EDT