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

Remi Forax forax at univ-mlv.fr
Tue Jul 11 15:07:21 EDT 2017


----- 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 ?

> 
> -Doug

Rémi


More information about the Concurrency-interest mailing list