hg: valhalla/valhalla/jdk: VarHandles for int/long arrays.

[Remi Forax]

On 10/30/2014 11:18 AM, Paul Sandoz wrote:
> Hi Remi,
>
> On Oct 29, 2014, at 8:05 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> On 10/22/2014 06:25 PM, paul.sandoz at oracle.com wrote:
>>> Changeset: fff1c746733f
>>> Author:    psandoz
>>> Date:      2014-10-22 18:08 +0200
>>> URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/fff1c746733f
>>>
>>> VarHandles for int/long arrays.
>>>
>>> + src/java.base/share/classes/java/lang/invoke/ArrayIntHandle.java
>>> + src/java.base/share/classes/java/lang/invoke/ArrayLongHandle.java
>>> ! src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
>>> ! src/java.base/share/classes/java/lang/invoke/VarHandles.java
>>> ! test/java/lang/invoke/VarHandleTest.java
>>>
>> Hi Paul,
>> I'm wondering if for any Array*Handle.getVolatile() instead of using unsafe to get the value,
>> it was not better to get the value with an array[index] and use unsafe only to emit the right fence ?
>>
> I think that is possible to do, and should result in better code generation for bounds checks.

and also better code generation by example when multiple writes are done 
on the same field.

>   But, we still have compareAndSet/getAndSet etc.

yes, anyway if at the end only compareAndSet, getAndAdd stay as unsafe 
intrinsics, I will call it a big achievement.

>
> So at the moment i would prefer to leave as is and wait for better optimization of bounds checks (and/or an intrinsic for Integer.compareUnsigned, which could also be useful in nio Buffer implementations):
>
>    https://bugs.openjdk.java.net/browse/JDK-8042997
>    https://bugs.openjdk.java.net/browse/JDK-8003585

While these bugs need to be fixed, using fences can also provide an 
interesting point of comparison.

>
> Paul.
>
>

Rémi