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

mandy chung mandy.chung at oracle.com
Wed Jul 11 23:22:28 UTC 2018

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

More information about the valhalla-dev mailing list