[Fwd: Re: JavaMemoryModel: Interaction between the memory model and exceptions]

From: Vijay Saraswat (vijay@saraswat.org)
Date: Sun Apr 11 2004 - 18:59:48 EDT


Reposting, havent seen this on the list yet, though have seen later
messages...

-------- Original Message --------
Subject: Re: JavaMemoryModel: Interaction between the memory model and
exceptions
Date: Sun, 11 Apr 2004 08:41:58 -0400
From: Vijay Saraswat <vijay@saraswat.org>
To: David Holmes <dholmes@dltech.com.au>
CC: Bill Pugh <pugh@cs.umd.edu>, jmm <JavaMemoryModel@cs.umd.edu>
References: <NFBBKALFDCPFIDBNKAPCIELCEAAA.dholmes@dltech.com.au>

David Holmes wrote:

>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.
>
Right.

This is one of my concerns -- the practical import of requiring precise
exceptions, and having many instructions that may throw such exceptions
(e.g. method invocation, field invocation, casts, array value
reference) is that the kind of code motion that the JMM was designed to
facilitate might not yield anywhere near the benefit one might have
hoped for.

Still waiting to hear from people who might have real experience with
high-performance multi-processor implementations of Java who might
(dis-)confirm this.

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