hg: valhalla/valhalla: 8205549: [lworld] Unsafe support for flattened field of value type

[mandy chung]

On 7/11/18 3:08 PM, Karen Kinnear wrote:
> Mandy,
> 
> Many thanks for jumping in and figuring this out so quickly.
> 
> I had some questions about follow-on steps you were planning for lw1
> please - could you possibly file lw1 bugs for the steps you are
> planning to do so we can sync up?
> 
> 1. Flattened arrays — AFAICT you have implemented unsafe support for
> value types in fields for MethodHandles, VarHandles and Reflection. 
> What were your plans for array support? If you add new APIs here, can
> we disallow a base of zero and require a base that is an array?


https://bugs.openjdk.java.net/browse/JDK-8205698

I'm waiting for the discussion with David when he returns from
vacation, in particular to understand any reason why the current
implementation to write an element in an array requires to
specify raw_byte_size.  One idea is to get Unsafe::arrayBaseOffset
and arrayIndexScale along with Unsafe::getValue/putValue to support
flattened arrays.

> 2. There were several proposals for explicit new API points for
> getReference/putReference (your call on naming) and friends that
> would know they were dealing with objects. Are you planning to add
> those for lw1?
> 
> And the C2 folks would move the intrinsics today used for
> getObject/putObject to be used for the new
> getReference/putReference. They need to know your timing here
> please.

I was thinking getReference/putReference can be done post-LW1.
I assume no LW1 dependency and urgency??

> 3. getObject/putObject and variations
> 
> See attached proposal - John bought into steps 1-3. So
> 
> Step 2: Were you planning to move conditional logic to
> jdk.internal.misc.unsafe to split into calls to getValue/getReference
> for lw1?
> 
> Step 3: Are there other JDK uses of getObject/putObject variations
> that you would change to explicitly use getValue/putValue or
> getReference/putReference?

There are other JDK uses of Unsafe::getObject/putObject such as
java.io.File, ObjectStreamClass, Graal compiler etc and many tests
using it.  It's straight-forward to rename them.

> What I had proposed was that internal to the JDK we switch over to
> using the explicit new APIs. This could allow Remi’s proposal of
> moving the getObject/putObject split logic into sun.misc.unsafe

It may be good to do all these together:
    https://bugs.openjdk.java.net/browse/JDK-8207146

Do you see any of these is critical for LW1?

Mandy

> 4. Immutability For the record I share Frederic’s concern - if you
> write to a value type that has its default value you overwrite the
> default value for that type. Looks like for lw1 folks want to allow
> this.
> 
> 5. Writing null. Sounds like John wants this to be the user’s
> problem, with unpredictable results. Agree with not automatically
> replacing null with a default value.
> 6. For lw1, the vm does not support atomics/volatiles for value
> types. So glad you added a java workaround.
> 
> thanks, Karen