[lworld] RFR JDK-8207259: Ensure VarHandle compare and set/exchange work for value types

[mandy chung]

On 8/15/18 1:07 PM, Remi Forax wrote:
 > Hi Mandy,
 >
> the use of Objects.equals to test two values is i believe
> wrong because a value type can have its method equals overriden but
> here you want to test the component wise equality bypassing the user
> defined equals.

Ah, good catch.  This should use System::substitutabilityTest when
present.  I will look into that next.

> and as a meta/spec comment, i do not think that using a lock is the
> right semantics, we should not allow compareAndSet on values, as a
> user if i use a CAS i want the platform to use a CAS (or equivalent)
> not a lock, it's important that the performance model of Java stay
> predictable for a user so we need a flag flattenIfAtomic which avoid > flattening a field if the platform is not able to perform a CAS on
> the flattened value of that field. A volatile field is implicitly
> flattenIfAtomic, but because we can do a CAS without the field been
> marked volatile using VarHandles, we need a separated flag.

I was also in that line of thought whether compareAndSet on values
should be allowed.  Using a lock is a workaround to allow further
exploration as in this prototype.

BTW this patch is specific to CAS on non-flattened value fields.
The flattenIfAtomic flag seems to concern on CAS on flattened value
fields.

Mandy
[1] 
http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-June/004509.html