Jerry -
I'm not sure why you'd want to perform this particular transformation, since x would be a field in the heap, and it would generally be far cheaper to keep the intermediate result elsewhere.
Admittedly, it also prevents you from
a) profiling your code and determining that x is usually 42 at some point,
b) reoptimizing your code assuming that x is 42, with a later check that it actually is, and then
c) rerunning the code on different input.
I suspect that this can be profitable at times.
On the other hand, in a Java context, this (and any out-of-thin-air generation) is clearly unsafe for object references, since it might give me access to objects I'm not supposed to see, or a completely bogus pointer. So we'd need two sets of rules, and would still need the messy specification for pointers. This doesn't sound very pleasant to me.
Hans
-----Original Message-----
From: Jerry Schwarz [mailto:jerry.schwarz@oracle.com]
Sent: Friday, July 25, 2003 2: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