hg: valhalla/valhalla/jdk: VarHandles for int/long arrays.
forax at univ-mlv.fr
Thu Oct 30 20:12:19 UTC 2014
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):
While these bugs need to be fixed, using fences can also provide an
interesting point of comparison.
More information about the valhalla-dev