[concurrency-interest] Should I avoid compareAndSet with value-based classes?
scolebourne at joda.org
Wed Jul 12 06:15:13 EDT 2017
As the author of Instant, what I would really like is for == to mean
.equals(). Of course I might not get my wish.
On 11 July 2017 at 20:07, Remi Forax <forax at univ-mlv.fr> wrote:
> ----- Mail original -----
>> De: "Doug Lea" <dl at cs.oswego.edu>
>> À: concurrency-interest at cs.oswego.edu
>> Envoyé: Mardi 11 Juillet 2017 19:55:14
>> Objet: Re: [concurrency-interest] Should I avoid compareAndSet with value-based classes?
>> On 07/11/2017 01:48 PM, Aleksey Shipilev wrote:
>>> Ah, quoting http://cr.openjdk.java.net/~jrose/values/values-0.html:
>>> "Many of the above restrictions correspond to the restrictions on so-called
>>> value-based classes. In fact, it seems likely that the boxed form of every value
>>> type will be a value-based class."
>>> So this seems to imply that identity-wise:
>>> "value type" < "value-based class" < "ordinary class".
>> Yes, thanks for nicely capturing what Remy and I were trying to get
>> across last week. My understanding of Gil's suggestions
>> about treating value-based class as values is that they are only
>> valid if a compiler does enough global analysis to be sure there
>> is no possible reliance on identity (including ==).
> It's more:
> "value type" -> acts as real values, boxing on stack may occur in the interpreter but it's transparent because value types are non mutable.
> "value-based class" / "value capable class" -> boxed by default, can be unboxed by the JIT and re-boxed at the edge by partial escape analysis, so == may compare different boxes.
> "ordinary class" -> can be unboxed by escape analysis but it has to be pessimistic, i.e. need to be sure that no code contains a ==.
> and for the astute reader, which kind of type is java.lang.Integer ?
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest