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

[Karen Kinnear]

Given John’s call on the unsafe philosophy

- you need to know what you are doing
- we won’t check for overwriting immutable - even if you overwrite canonical default
- we won’t prevent writing nulls
- we won’t prevent reading/writing first element of flattened field when you think you are getting a reference

— well - seems like LW1 is a good place to find out reactions to that - so we will put in a warning on the public
wiki.

So - translation is - Mandy - if you could add the VarHandles array support then I think we are all set as your propose
for LW1. 

this means we also don’t need to change the current intrinsics for getObject/putObject and won’t put back Frederic’s
changes. Many thanks to Frederic for the miracle and hope vacation helps recovery.

Seat belts please,
thanks,
Karen

> On Jul 11, 2018, at 7:40 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Jul 11, 2018, at 4:22 PM, mandy chung <mandy.chung at oracle.com <mailto: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 <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 <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.