RE: JavaMemoryModel: Updated JMM schedule and status report

From: Jerry Schwarz (jerry.schwarz@oracle.com)
Date: Mon Jul 28 2003 - 03:36:18 EDT

At 07:31 AM 7/26/2003, Sarita Adve wrote:

Jerry, why do you think this is not allowed by the out-of-thin-air requirement?
 


Because after the transformation y might be 3*c, but without the transformation there is no assignment to x with value 3*c, so  y==3*c  is "out of thin air".

Bill/Jeremy - does your model prohibit this? If so, how and why?
 

By the way, someone else (Hans?) asked why a compiler would ever want to do this transformation.
Consider a stituation in which 3*c had been needed earlier, because of register pressure it had to be stored somewhere and the compiler was being asked to do extreme optimization for space.

Perhaps that scenario is unlikely but it isn't impossible.

Thanks,
 
Sarita
-----Original Message-----
From: owner-javamemorymodel@cs.umd.edu [mailto:owner-javamemorymodel@cs.umd.edu] On Behalf Of Jerry Schwarz
Sent: Friday, July 25, 2003 4:00 PM
To: jmanson@cs.umd.edu; javamemorymodel@ringding.cs.umd.edu
Subject: Re: JavaMemoryModel: Updated JMM schedule and status report


Personally, I always thought the no out of thin air requirement was unreasonable. Among other things it constrains optimizers in ways that have nothing to do with threading and synchronization.  That is, I've always taken the goal to be to allow the optimizer to treat straight line code without any thread related operation (however that is defined) as if no threading were present.  But consider
Thread 1
c = ...
x = 3 * c - 1
Thread 2
y = x

The not out of thin air requirement says that the compiler can't transform Thread 1 to
c = ...
x = 3 * c
x = x - 1




At 09:48 AM 7/25/2003, jmanson@cs.umd.edu wrote:
The list has deemed it necessary to provide some causal guarantees for
Java.  For example, out of thin air safety:

Thread 1
x = y

Thread 2
y = x

We have agreed long since that this cannot, for example, result in x = y =
42.  There are other, more meaningful examples of out-of-thin-air results
that are widely agreed upon.

                                        Jeremy

----- Forwarded message from Paul Loewenstein -----

From: Paul Loewenstein <Paul.Loewenstein@sun.com>

It is now over 10 years since I was last involved in writing a memory
model (Sparc V9).  In the interests of simplicity the RMO model admits
non-causal traces.  The cure was deemed worse than the disease.  The
only effect would be some unnecessary synchronization in somewhat
obscure and unlikely code.  Is relaxing the Java memory model for the
sake of simplicity a viable option?

Paul
----- End of forwarded message from Paul Loewenstein -----
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
------------------------------- JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
------------------------------- JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:46 EDT