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

[John Rose]

On Jul 11, 2018, at 4:22 PM, mandy chung <mandy.chung at oracle.com> wrote:
> 
> 
> 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

Oops: My previous comment that MHs array support  "Just Works"
is only true for the one API point MHs.arrayElementGetter; it is not
true for VH API points which must use Unsafe to implement volatile
access.

> 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.

See http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-July/004515.html
(on this list) for a brief discussion of array indexing.  The array stride is
potentially different from (larger than) the actual size of the value type.
That might be the reason for the extra parameter.  If that's so, then
you just do the natural thing and it will work:  Scale the displacement
by the arrayIndexScale and then use Unsafe.putValue, which will
use the correct byte-size even if that is smaller than the array stride.

> 
>> 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??

(I am aware of none.  But Karen knows more than me about successfully
docking the Good Ship LW1.)

> 
>> 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.

I'm glad to hear this.  This is the sort of refactoring that Mark was
envisioning when he first got that funny "modules look" in his eye,
so many years ago.

> 
>> 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?

(Same comment from me as before.)

Thanks for doing this Mandy!

— John

P.S. Also, let's think a bit about doing those brackets for value types.
One more thought about that:  The opening bracket could return
a buffer that is just an untyped Object with different markings than
a real Point instance.  The closing bracket could take the untyped
object *and* a Class mirror for the desired value type, which of course
would have to match the input that created the buffer.  For example,
the buffered object could have the same klass field as an instance,
but a different mark-word bit pattern, that was reserved only for
this particular place in the Unsafe API.