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