Should I avoid compareAndSet with value-based classes?

classic Classic list List threaded Threaded
101 messages Options
1 ... 3456
Reply | Threaded
Open this post in threaded view
|

Re: Should I avoid compareAndSet with value-based classes?

Vitaly Davidovich
== vs equals() also has the difference that equals is an implicit null check.  JIT can optimize around that, but it's an impl detail.  So long as these value based classes are still reference types (with nullness, synchronizability, identity), it's not going to work well.

It would've been nice to wait for VT (or have VT a priority for earlier Java releases) to unleash the java.time, Optional, and the like "properly", but that ship has sailed.  Commingling true value types with value based/like classes will result in surprises for Java users.  As I mentioned, these surprises need to be eliminated at the type system level where the compiler and verifier refuse bogus code.

On Wed, Jul 12, 2017 at 9:52 AM Nathan and Ila Reynolds <[hidden email]> wrote:
At first, I thought I wouldn't want == to mean equals(). However, String
consumes a lot of heap space.  G1 GC already can de-duplicate the
char[]/byte[] inside String to reduce memory usage.  But, G1 GC can't
de-duplicate the String objects themselves because it could break code
which relies on the fact that equals() does not mean ==.  So, if this
constraint could be relaxed for String, then additional heap savings is
possible.  If this constraint were relaxed for all immutable classes,
then additional heap savings is possible but insignificant for the
general case.

-Nathan

On 7/12/2017 4:44 AM, Alex Otenko wrote:
> That shouldn’t be a problem for some well-behaving types. Immutable types certainly could behave like that - that’s the behaviour when there is a single instance for any value.
>
> Since there is never a “direct” way to CAS values, it would be the job of the AtomicFieldUpdater to do “the right thing” for values that are such special values for which people struggle to formulate an uncontentious javadoc about its “==“ and its impact on CAS.
>
> Alex
>
>> On 12 Jul 2017, at 11:18, Kirk Pepperdine <[hidden email]> wrote:
>>
>>
>>> On Jul 12, 2017, at 1:15 PM, Stephen Colebourne <[hidden email]> wrote:
>>>
>>> As the author of Instant, what I would really like is for == to mean
>>> .equals().
>> Really? There is a definitive semantic difference between == and equals() and I’m trying to sort out why anyone would want to confuse them.
>>
>> Kind regards,
>> Kirk
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> [hidden email]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

--
-Nathan

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
--
Sent from my phone

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
1 ... 3456