hg: valhalla/valhalla/jdk: VarHandles for int/long arrays.
paul.sandoz at oracle.com
Fri Oct 31 13:52:10 UTC 2014
On Oct 30, 2014, at 9:12 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 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.
Perhaps, i would need to experiment with fences + aastore/load vs. Unsafe.
>> 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.
There is an edge case where we may still need to consistently use Unsafe, specifically for long values and platforms that do not support 64-bit CAS, see:
More information about the valhalla-dev