<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div>With all this said (and I absolutely think that e.g. it should be expected that loops like my examples from the previous post may never terminate), this discussion has made me come up with a way to (I *think*) safely apply CAS to instances of Instant (and
 on any other instances that happen to be of value-based classes) as long as we code the CAS and the type it operates on carefully. I believe it is safe to do so as long as the field being CAS'ed into is declared as an Object and NOT as an Instant. By casting
 from Object to Instant to perform Instant operations [e.g. adding a duration] while preserving the Object form for the thing being compared in the CAS operation, I believe the CAS remains valid. See code below.</div>
<div><br class="">
</div>
<div>The reason that I believe this approach is inherently safe is that the contents of fields and local variables of type Object are [I think] required to retain identity-sensitive operation behaviors regardless of the actual (derived from Object) type of
 the current contents. The contents of fields and variables *known* to be of type Instant (and of other value-based classes that are inherited from Object) may lose identity information and produce unpredictable behaviors when used with identity-sensitive operations,
 based on the specification of the behaviors of value-based classes. However, this freedom to lose track of identity does not extend to fields and variables of type Object (or other non-value-based classes). </div>
<div><br class="">
</div>
<div>In effect, I believe that the JVM is required to "box" instances of value-based classes in actual object references to actual objects with actual identity when storing them in fields or variables of a type that is not a value-based class. And all identity-based
 operations done on those fields and variables remain as-expected regardless of whether or not the contents is a reference to an instance of a value-based class. This quality is lost once something is cast to a value-based class (for storage in either a variable
 or field). In back-and-forth casting (implicit or explicit), the identities of objects that are created by casting back to Object does not have to remain the same as the identities of the original Objects cast from to a value-based class.</div>
<div><br class="">
</div>
<div>[** in this logic, "field" includes an array element]</div>
<div><br class="">
</div>
<div>This also leads me to [partially] retract my suggestion for throwing exceptions when encountering identity-based operations on instances of value-based classes. Such exceptions clearly shouldn't be thrown when the declared types of the operands involved
 are not value-based classes (even if the contents is of those type). I still think that throwing exceptions when the declared types are value-based classes could make sense, but this can actually be done better by the Java compiler refusing to compile such
 code (and it should know enough to do that, since the types are declared).</div>
<div><br class="">
</div>
<div>Since Generics do reification, this stuff would be un-enforceable in the generics source code. But it can still be enforced in code that uses generics, e.g. a AtomicReference<Object>.compareAndSet() can still refuse [at compile time] to accept a declared-as-value-based-class
 type as it's "expected" parameter. </div>
<div>
<pre style="background-color: rgb(255, 255, 255); font-family: Menlo; font-size: 9pt;" class=""><pre style="font-family: Menlo; font-size: 9pt;" class=""><span style="color:#000080;font-weight:bold;" class="">public class </span>MutableClock {<br class=""><br class="">    <span style="color:#000080;font-weight:bold;" class="">public static </span>MutableClock create(<span style="color:#000080;font-weight:bold;" class="">final </span>Instant instant, <span style="color:#000080;font-weight:bold;" class="">final </span>ZoneId zone) {<br class="">        <span style="color:#000080;font-weight:bold;" class="">return new </span>MutableClock(<br class="">                <span style="color:#000080;font-weight:bold;" class="">new </span>AtomicReference<>(instant),<br class="">                zone);<br class="">    }<br class=""><br class="">    <span style="color:#808080;font-style:italic;" class="">// Instants are held in an Object field to allow identity-based CAS operations:<br class=""></span><span style="color:#808080;font-style:italic;" class="">    </span><span style="color:#000080;font-weight:bold;" class="">private final </span>AtomicReference<Object> <span style="color:#660e7a;font-weight:bold;" class="">instantHolder</span>;<br class="">    <span style="color:#000080;font-weight:bold;" class="">private final </span>ZoneId <span style="color:#660e7a;font-weight:bold;" class="">zone</span>;<br class=""><br class="">    <span style="color:#000080;font-weight:bold;" class="">private </span>MutableClock(<br class="">            <span style="color:#000080;font-weight:bold;" class="">final </span>AtomicReference<Object> instantHolder,<br class="">            <span style="color:#000080;font-weight:bold;" class="">final </span>ZoneId zone) {<br class="">        <span style="color:#000080;font-weight:bold;" class="">this</span>.<span style="color:#660e7a;font-weight:bold;" class="">instantHolder </span>= instantHolder;<br class="">        <span style="color:#000080;font-weight:bold;" class="">this</span>.<span style="color:#660e7a;font-weight:bold;" class="">zone </span>= zone;<br class="">    }<br class=""><br class="">    <span style="color:#000080;font-weight:bold;" class="">public </span>Instant instant() {<br class="">        <span style="color:#000080;font-weight:bold;" class="">return </span>(Instant) <span style="color:#660e7a;font-weight:bold;" class="">instantHolder</span>.get();<br class="">    }<br class=""><br class="">    <span style="color:#000080;font-weight:bold;" class="">public </span>ZoneId getZone() {<br class="">        <span style="color:#000080;font-weight:bold;" class="">return </span><span style="color:#660e7a;font-weight:bold;" class="">zone</span>;<br class="">    }<br class=""><br class="">    <span style="color:#000080;font-weight:bold;" class="">public void </span>setInstant(<span style="color:#000080;font-weight:bold;" class="">final </span>Instant newInstant) {<br class="">        <span style="color:#660e7a;font-weight:bold;" class="">instantHolder</span>.set(newInstant);<br class="">    }<br class=""><br class="">    <span style="color:#000080;font-weight:bold;" class="">void </span>add(Duration amountToAdd) {<br class="">        <span style="color:#000080;font-weight:bold;" class="">boolean </span>success = <span style="color:#000080;font-weight:bold;" class="">false</span>;<br class="">        <span style="color:#000080;font-weight:bold;" class="">do </span>{<br class="">            Object currentContents = <span style="color:#660e7a;font-weight:bold;" class="">instantHolder</span>.get();<br class="">            <span style="color:#808080;font-style:italic;" class="">// ((Instant) currentContents) may have no identity, but currentContents does...<br class=""></span><span style="color:#808080;font-style:italic;" class="">            </span>Instant newInstant = ((Instant) currentContents).plus(amountToAdd);<br class="">            <span style="color:#808080;font-style:italic;" class="">// Compare part of CAS would not be valid for an Instant field,<br class=""></span><span style="color:#808080;font-style:italic;" class="">            // but is valid for an Object field:<br class=""></span><span style="color:#808080;font-style:italic;" class="">            </span>success = <span style="color:#660e7a;font-weight:bold;" class="">instantHolder</span>.compareAndSet(currentContents, newInstant);<br class="">        } <span style="color:#000080;font-weight:bold;" class="">while </span>(!success);<br class=""><br class="">        <span style="color:#808080;font-style:italic;" class="">// the above is equivalent to this, I believe:<br class=""></span><span style="color:#808080;font-style:italic;" class="">        //   instantHolder.updateAndGet(instant -> ((Instant)instant).plus(amountToAdd));<br class=""></span><span style="color:#808080;font-style:italic;" class="">    </span>}<br class=""><br class="">    <span style="color:#000080;font-weight:bold;" class="">public </span>MutableClock withZone(<span style="color:#000080;font-weight:bold;" class="">final </span>ZoneId newZone) {<br class="">        <span style="color:#808080;font-style:italic;" class="">// conveniently, AtomicReference also acts as a<br class=""></span><span style="color:#808080;font-style:italic;" class="">        // vehicle for "shared updates" between instances:<br class=""></span><span style="color:#808080;font-style:italic;" class="">        </span><span style="color:#000080;font-weight:bold;" class="">return new </span>MutableClock(<span style="color:#660e7a;font-weight:bold;" class="">instantHolder</span>, newZone);<br class="">    }<br class="">}</pre><div class=""><br class=""></div></pre>
<div class=""><br class="">
</div>
</div>
<div><br class="">
</div>
<div><br class="">
</div>
<div>
<blockquote type="cite" class="">
<div class="">On Jul 8, 2017, at 5:22 AM, Gil Tene <<a href="mailto:gil@azul.com" class="">gil@azul.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="">On Jul 8, 2017, at 1:19 AM, Andrew Haley <<a href="mailto:aph@redhat.com" class="">aph@redhat.com</a>> wrote:<br class="">
<br class="">
On 08/07/17 07:38, Gil Tene wrote:<br class="">
<br class="">
<blockquote type="cite" class="">My arguments here are not about trying to justify some compiler<br class="">
optimizations, or trying to justify the choices of making these<br class="">
things subclasses the Object. They are about pointing out the actual<br class="">
meaning of things as defined and the (very high risk) of coding<br class="">
against it based on a hope that some temporarily observed behavior<br class="">
is actually reliable, when everything that describes what it does<br class="">
says otherwise.<br class="">
</blockquote>
<br class="">
I disagree with this interpretation.  You're interpreting the language<br class="">
in that paragraph as overriding some fundamental properties in the JLS.<br class="">
</blockquote>
<br class="">
To keep this to a simple case that<br class="">
<br class="">
What specific property of the JLS requires that == not be always-false?<br class="">
<br class="">
I.e., what is it in the JLS that requires that this loop ever terminate when there is no external interference by another thread?:<br class="">
<br class="">
 // David Lloyd's example from earlier in the thread (Jul 6, 10:48AM PDT):<br class="">
 AtomicReference<Instant> atomic;<br class="">
 Instant a, b;<br class="">
 ...<br class="">
 do {<br class="">
     a = atomic.get();<br class="">
     b = compute(a);<br class="">
 } while (! atomic.compareAndSet(a, b));<br class="">
<br class="">
<br class="">
or for that matter, that this loop ever terminate when there is no external interference by another thread?:<br class="">
<br class="">
 volatile Instant thing;<br class="">
 Instant a, b;<br class="">
 …<br class="">
 boolean success = false;<br class="">
 do {<br class="">
     a = thing;<br class="">
     b = compute(a);<br class="">
     if (thing == a) {<br class="">
         thing = b;<br class="">
         success = true;      <br class="">
     }<br class="">
 } while (!success);<br class="">
<br class="">
The termination of both of these loops relies on the notion of identity (the logical value of a reference) being preserved between the reading of a reference to an instance of a value-based class from memory, and the eventual comparison of that instance's reference
 with another one stored in a memory location.<br class="">
<br class="">
I'm really asking… I'd love to find something in the JLS that says this must be preserved, and thereby contradict the statements that say that instances of value-based classes "are freely substitutable when equal" and "Use of such identity-sensitive operations
 on instances of value-based classes may have unpredictable effects". <br class="">
<br class="">
I'd like to point out that Instant happens to be one of those cool ""partially compressible value" classes who's value cannot be fully represented with a single 64 bit value, but where "a wide and interesting range" of values can be: specifically, all the possible
 values of Instant between the epoch and some time in the year 2043 *can* be represented in 63 bits, making smalltalk-like inlined "it's not a pointer, it's a value" representations very possible (e.g. negative references are actual the values) and appealing
 for many reasons (both space and speed). This works as long as both identity and type can be erased from the contents without hurting computations [which can be done safely when stored in registers whose type is known, for example]. And this quality is specifically
 provided by the documentation of the type as a value-based class.<br class="">
<br class="">
However, since it is possible for instances of Instant to be stored in locations that do not have this quality [e.g. Object fields, or even known-to-be-of-type-Instant fields in memory depending on implementation], each possible "compressible value" also needs
 a non-compressed representation in a heap-based object contents form. This means that the value in the memory location may be a true reference, while the value we read into local variables may not be, at least for a wide range of possible values. And that
 in turn means that the loops above will never terminate (since they will never be able to show that the reference contents of "atomic" or of "thing" is == to the value in a).<br class="">
<br class="">
<blockquote type="cite" class=""><br class="">
In the case of C, the thing to do would be to ask for a clarification,<br class="">
but I suspect that if we asked, say, John Rose, Alex Buckley, and<br class="">
Brian Goetz we'd get different answers.  ;-)<br class="">
<br class="">
-- <br class="">
Andrew Haley<br class="">
Java Platform Lead Engineer<br class="">
Red Hat UK Ltd. <<a href="https://www.redhat.com" class="">https://www.redhat.com</a>><br class="">
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671<br class="">
</blockquote>
<br class="">
_______________________________________________<br class="">
Concurrency-interest mailing list<br class="">
<a href="mailto:Concurrency-interest@cs.oswego.edu" class="">Concurrency-interest@cs.oswego.edu</a><br class="">
http://cs.oswego.edu/mailman/listinfo/concurrency-interest<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</body>
</html>