[concurrency-interest] Should I avoid compareAndSet with value-based classes?
Nathan and Ila Reynolds
nathanila at gmail.com
Wed Jul 12 09:51:19 EDT 2017
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
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.
>> On 12 Jul 2017, at 11:18, Kirk Pepperdine <kirk at kodewerk.com> wrote:
>>> On Jul 12, 2017, at 1:15 PM, Stephen Colebourne <scolebourne at joda.org> wrote:
>>> As the author of Instant, what I would really like is for == to mean
>> 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,
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest