At 4:02 PM -0400 9/13/01, Jan-Willem Maessen wrote:
>> >2) A write may be reordered across a control flow boundary iff it can
>> > be shown that the particular write will occur in any execution,
>> > regardless of the existence or behavior of other threads in the
>> > system.
>And Bill Pugh <email@example.com> replied:
>> OK, a very important point regarding control dependences:
>> *** Any operation is control dependent upon all preceding operations
>> that could throw an exception.
>> So your rule (2) makes illegal any analysis that uses non-local
>> information to determine that an operation cannot throw an exception.
>Nonsense. The only thing that could possibly be prohibited in
>practice is _reordering_ based on this information; we wouldn't be
>able to tell if we did all sorts of other transformations (like
>removing exception handlers and exception points, eliding tests,
>etc.). We can simplify as much as we like.
OK, you can actually eliminate the null-pointer check or array bounds
check. But you need to leave in place a compiler memory barrier that
prevents the compiler from reordering around a location where you've
determined an exception cannot occur.
Furthermore, on processors that allow a read to be reordered with a
following write, you may need to issue a memory fence/barrier
VM implementors will not be happy about this, since it seems so
completely useless. I doubt you could get VM implementor to generate
the appropriate compiler memory barriers.
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