RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe

[Karen Kinnear]

Thank you all for the rapid responses and prototyping.

Based on John/Paul/Remi’s suggestions - this is what I propose we do for LW1:
(Roland, Tobias - intrinsics questions embedded please)

I. New APIs:
Add new unsafe APIs for getValue/putValue and getReference/putReference (your choice of names)
and get to them as Remi suggested via jdk.internal.misc.unsafe.

    - Use the new APIs from MethodHandles/VarHandles/Reflection (as Mandy is prototyping)

II. getObject/putObject handling

I like the combined suggestions of:
    - jdk.internal.misc.unsafe - remove getObject/putObject and friends - as you have time,
    migrating all the callers to use the new APIs.
    - sun.misc.unsafe
      - this currently redirects you to jdk.internal.misc.unsafe
      - your call how you do this - this would be the place to have the value-aware version

Step 1:
   Have Frederic check in his native changes including getObject/putObject native changes. Remove @HotspotIntrinsic for getObject/putObject.
Step 2:
   Move the conditional logic to jdk.internal.misc.unsafe which will call getValue/getReference as appropriate.
   Please move ALL the logic in the native version to java - making sure to cover all the cases the native version
   is covering today.

Step 3: If you have time 
- Remove jdk.internal.misc.unsafe.getObject/putObject - and replace all jdk uses with the new calls,
  possibly moving the logic out to sun.misc.unsafe.

IV. Intrinsics
  Roland, Tobias 

My expectation of intrinsics is:
  1. The new getReference/putReference will use exactly the same code as today’s getObject/putObject, so
it could use the same intrinsics
  2. The new getValue/putValue will need new intrinsics - which have additional challenges for example due to scalarization
  3. getObject/putObject will no longer be intensified

IV. Immutability
  Immutability is not just a good idea, …
  Immutability is not the same as final - sorry - we actually count on it.
  I highly recommend that even through unsafe - value types are immutable.

V. Nullability
  In LW1, all instance fields of value types are flattenable and non-nullable. 
  We have the option in putValue of not allowing writing null to an value type instance field.
  Let’s start with that assumption.
  We intend to add flattenable static fields shortly after LW1, so we should disallow writing
  null to flattenable value type static fields.

Open Questions:
1. atomic/volatile/etc. What can you do at the java level?
We don’t currently support atomic flattenable value types.


thanks,
Karen

p.s. I will be out on vacation next week, back the week after - don’t let me slow you down

> On Jun 29, 2018, at 2:58 PM, mandy chung <mandy.chung at oracle.com> wrote:
> 
> 
> 
> On 6/29/18 9:23 AM, Paul Sandoz wrote:
>> View nice!
>> Comments for further iteration perhaps after committing:
>> - You may want to follow the same pattern for getType as for
>> fieldOffset i.e. use a static method rather than a virtual method.
> 
> I added static fieldValueType for Accessor and staticFieldValueType
> for StaticAccessor that might help the performance (no data).
> 
> I am in two mind if I should prepare the static field case as
> hotspot does not flatten static field.  For now, I keep it there
> and should revisit it at some point.
> 
>> - We can remove the atomic add and bitwise ops from
>> ValueFieldInstanceReadWrite.
> 
> Good catch.  I took that out.
> 
>> - The Unsafe atomic accessors ValueVolatile/Acquire/Release/Opaque
>> can use a global lock for the moment to ensure atomicity and
>> ordering, the acquire/release can defer to the volatile accessors.
>> Adding the others is also straightforward (weaker CAS and CAE can
>> defer to the volatile CAS/CAE methods).
>> Happy to help with any of this with following patches.
> 
> Thanks.  I wanted to look at volatile/acquire/release/opaque and
> other ops separately and will definitely ask your help.  So no lock
> at the moment and hope it's okay.
> 
> Revised webrev:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/unsafe-flat-fields-webrev.01/
> 
> Mandy
>