At 4:03 PM +0200 8/22/01, R.S. Veldema wrote:
>Hi, im in the process of writting my thesis on Java on a DSM:
>http://www.cs.vu.nl/~rveldema/jackal
>Where in my thesis Id like to advocate that im using your jsr 133 JMM
>instead of SUN's JMM. Now I came across the following (hopefully
>minor) problem;
>what happens to working memory after an exception has been thrown.
>Is a throw a synchronization action that flushes main memory ?
>or does it not effect main memory at all ?
>What if the exception is not caught at all ?
>
>class T1 {
> int field;
> int a[] = new int[5];
>
>// will other threads observe that field = 1 ?
> void test1() throws Exception {
> field = 1;
> a[10] = 3; <--- bounds check+exception that is not caught anywhere
> }
>}
>
>
>Also, I'd like to be able to move code over
>bounds checks, and memory references (may throw null-pointer exception)
>If a throw flushes memory I might have a problem.....
>If a catch statement were to flush memory, this problem would be
>solved. especially as I don't expect these to occur too often.
>
>
>Thanks in advance.
>Ronald.
Exceptions do not behave as synchronization operations. However,
exceptions do have strict semantics. In particular, if the thread in
which the exception is thrown later reads "field", it must see the
update.
Now you are considering a case in which the compiler can prove that
the exception is not caught by the thread and that no synchronization
actions are performed in any explicit or implicit finally blocks
(e.g., releasing locks). There are a number of ways in which other
threads can be guaranteed to be correctly synchronized with the
termination of the thread, in which case they are guaranteed to see
the update to "field":
* The ThreadGroup.uncaughtException method is correctly synchronized with the
thread termination and must see the update to "field".
* Any thread that uses Thread.join or Thread.isAlive to determine that the
thread has terminated is correctly synchronized with the
thread termination and must see the update to "field".
* Assuming the thread was a non-Daemon thread, all shutdown hooks added via
Runtime.addShutdownHook are correctly synchronized with the
thread termination and must see the update to "field".
So, there are lots of things you have to worry about in order to be
able to reorder writes over potential exceptions. On the other hand,
if you can prove that the reordering isn't detectable, go right
ahead. Perhaps one of the most promising approaches would be to prove
that the write is to a memory location that cannot be accessed if the
exception is thrown.
A related question that I would like some input on from people on the
list: are Errors guaranteed to be precise? What if the JVM throws an
InternalError or StackOverflowError? Is it required to be the case
that there exists some point in the original program such that all
writes before that point were committed and no writes after that
point are performed? What implementation strategies do JVMs use to
handle this?
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:34 EDT