[concurrency-interest] Should I avoid compareAndSet with value-based classes?
gil at azul.com
Tue Jul 11 14:32:08 EDT 2017
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) …
"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.
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu<mailto:Concurrency-interest at cs.oswego.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest