[concurrency-interest] Should I avoid compareAndSet with value-based classes?

Alex Otenko oleksandr.otenko at gmail.com
Tue Jul 11 14:52:14 EDT 2017


No, I draw a line around the visibility of assignments. If no assignment is in the code, the identity should not change - whether it is a reference equality, or bitwise equality of unboxed values.

I don’t pretend to understand the ramifications of this, but it seems the other languages solve this.

Alex

> On 11 Jul 2017, at 19:32, Gil Tene <gil at azul.com> wrote:
> 
>> 
>> On Jul 11, 2017, at 11:15 AM, Alex Otenko <oleksandr.otenko at gmail.com <mailto:oleksandr.otenko at gmail.com>> wrote:
>> 
>>> 
>>> On 11 Jul 2017, at 18:30, Aleksey Shipilev <shade at redhat.com <mailto:shade at redhat.com>> wrote:
>>>> ...
>>> I think "value-based class" language is provisional for "do not rely on
>>> identity, even if it is defined for the objects you will be getting". Integer,
>>> as you say, have already leaked the identity in public, and we are done there,
>>> the guy is disqualified.
>>> 
>>> In this parlance, saying "Instant is like primitive/Integer" is far worse
>>> language than actually spelling out the "unknown identity" rules with
>> 
>> Spelling out “unknown identity” is like “we don’t really know what we are doing”.
>> 
>> There is no similar problem with Integer, but not because of “public constructors”. It is because there is a clear separation between boxed context (Integer a), and unboxed context (int a).
>> 
>> The reference Remi quoted a few days ago is also more sensible than what we are talking about here. Even though I don’t like the language, clearly there’s a notion of boxing-unboxing instructions. Clearly, there are meant to be rules about where those instructions can and cannot go. Those rules determine the meaning of “==“.
>> 
>> I will expect the variable that is not assigned a different value to retain its “identity” within the lexical scope of the value’s visibility.
>> 
>> I will expect there will be no heisen-boxing - replacing unboxed values with boxed values, when the value is still observed in the lexical scope.
> 
> Does this means that you draw the line between local variables and heap storage (in e.g. fields or array elements)? As in:
> 
> B. (i1 == i1)  // always true
> C. (i1 == annotatedTime. instant) // May be true or false
> D. (annotatedTime1.isExactSameInstant(i1)) // May be true or false
> E. (i1 == instanceCache.get(1000L)) // May be true or false
> 
> That's interesting, as it can probably work ok. But it's probably hard to explain (can be freely substituted when reading from or writing to fields, but not in reading from or writing to local variables) …
> 
>> 
>> 
>> Alex
>> 
>>> "value-based class" text. Having these rules spelled out eases switching them to
>>> real value types, with appropriate spec changes. But, it does not give a blanket
>>> approval for doing so, it just minimizes the damage.
>>> 
>>> I understand one could claim "JVM is allowed to ignore identity for value-based
>>> classes, because it is claimed to be unpredictable anyway", and probably lawyer
>>> up to say it is spec-legal. Although it would be fun to see the defense where
>>> Javadoc trumps the core JLS.
>>> 
>>> Still, I think the interpretation of "identity stays unknown, but still behaves
>>> like an object" is saner from quality of implementation, principle of least
>>> astonishment, "don't break Java" standpoints.
>>> 
>>> How will Valhalla deal with these problems, we shall see. My bet is on
>>> value-type-specific comparisons (which should catch CAS in its wake), plus
>>> boxing where the references are needed (which would capitalize on what we
>>> learned to love about Java's primitives).
>>> 
>>> I think this CAS example is interesting to discuss in valhalla-dev@, where it
>>> actually matters, not here.
>>> 
>>> Thanks,
>>> -Aleksey
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu <mailto:Concurrency-interest at cs.oswego.edu>
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170711/7092c78d/attachment.html>


More information about the Concurrency-interest mailing list