[concurrency-interest] Should I avoid compareAndSet with value-based classes?
vitalyd at gmail.com
Wed Jul 12 13:11:47 EDT 2017
== 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 <nathanila at gmail.com>
> 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.
> 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 <kirk at kodewerk.com> wrote:
> >>> On Jul 12, 2017, at 1:15 PM, Stephen Colebourne <scolebourne at joda.org>
> >>> 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
> >> Concurrency-interest at cs.oswego.edu
> >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
Sent from my phone
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest