Helpers for MethodHandles.byteArrayViewVarHandle VarHandle
Hi, what do you thing about adding helper methods for this kind of VarHandle? It would be nice to have something like Long.getFrom[LE/BE](byte[] arr, int index) // LE/BE -> endianity Long.setTo[LE/BE](long val, byte[] arr, int index) or Arrays.getLongFrom[LE/BE](byte[] arr, int index) Arrays.setLongTo[LE/BE](long val, byte[] arr, int index) Jaroslav
Hi Jaroslav, I would prefer not to spread such functionality beyond that of ByteBuffer and the VarHandle producing methods on MethodHandles. It’s an advanced feature so think ok if less visible. Note at the moment a VarHandle produced for byte[]/ByteBuffer view is not cached but it is certainly possible to do so. — Separately, i may revisit the signatures for access to also include an alignment-offset argument (which is expected to be constant when looping) in addition to the index (e.g. byte-index = ao + (i << LOG_2_UNIT_SIZE)). Thus bringing alignment into the foreground where it is harder to forget about or ignore. Paul.
On 16 May 2016, at 15:48, Jaroslav Kameník <jaroslav@kamenik.cz> wrote:
Hi,
what do you thing about adding helper methods for this kind of VarHandle?
It would be nice to have something like
Long.getFrom[LE/BE](byte[] arr, int index) // LE/BE -> endianity Long.setTo[LE/BE](long val, byte[] arr, int index)
or
Arrays.getLongFrom[LE/BE](byte[] arr, int index) Arrays.setLongTo[LE/BE](long val, byte[] arr, int index)
Jaroslav
Hi, thank you for response!
I would prefer not to spread such functionality beyond that of ByteBuffer and the VarHandle producing methods on MethodHandles. It’s an advanced feature so think ok if less visible.
On the other side, this would be easier to use and understand than ByteBuffer in simple cases, I think. I have looked into JVM sources briefly, and this functionality is implemented often there, both inlined and methods as intAt/readLong/... So it could be helpful even as private api.
Separately, i may revisit the signatures for access to also include an alignment-offset argument (which is expected to be constant when looping) in addition to the index (e.g. byte-index = ao + (i << LOG_2_UNIT_SIZE)). Thus bringing alignment into the foreground where it is harder to forget about or ignore.
It is nice idea. So it could look like: getLongFrom[LE/BE](byte[] data, int firstByteIndex) - for direct access getLongFrom[LE/BE](byte[] data, int firstByteOffset, int longArrayIndex) - for loops/shifted array access etc. I'd like to ask about performance - how does wrapping of VH to another call affect optimization to simple memory load? Jaroslav
On 18 May 2016, at 16:50, Jaroslav Kameník <jaroslav@kamenik.cz> wrote:
Hi,
thank you for response!
I would prefer not to spread such functionality beyond that of ByteBuffer and the VarHandle producing methods on MethodHandles. It’s an advanced feature so think ok if less visible.
On the other side, this would be easier to use and understand than ByteBuffer in simple cases, I think.
I have looked into JVM sources briefly, and this functionality is implemented often there, both inlined and methods as intAt/readLong/... So it could be helpful even as private api.
There certainly is in nio buffer sources (and may be for encoding/decoding in other areas, i am speculating as i have not looked), but for buffer sources we can actually remove much if not all of Bits.java via use of the internal Unsafe unaligned accessors.
Separately, i may revisit the signatures for access to also include an alignment-offset argument (which is expected to be constant when looping) in addition to the index (e.g. byte-index = ao + (i << LOG_2_UNIT_SIZE)). Thus bringing alignment into the foreground where it is harder to forget about or ignore.
It is nice idea. So it could look like:
getLongFrom[LE/BE](byte[] data, int firstByteIndex) - for direct access getLongFrom[LE/BE](byte[] data, int firstByteOffset, int longArrayIndex) - for loops/shifted array access
etc.
I was proposing just the latter, and just for VarHandles :-) it’s not just for loops but also to bring alignment issues to the foreground. (It also it fits in with something we have been pondering about for the unsafe unaligned accessors on systems that don’t support unaligned access, such as SPARC).
I'd like to ask about performance - how does wrapping of VH to another call affect optimization to simple memory load?
Same as that of a MethodHandle getter/setter to a field. The compiler should strip away the all the “ceremony” and inline the access as if Unsafe was used directly (but with safety checks in place most of which are optimized away, although hard to fully elide array bounds checks in certain cases, but we try our best!) Paul.
There certainly is in nio buffer sources (and may be for encoding/decoding in other areas, i am speculating as i have not looked), but for buffer sources we can actually remove much if not all of Bits.java via use of the internal Unsafe unaligned accessors.
I made some notes when I was looking at it, I am attaching it if you want look at it.
getLongFrom[LE/BE](byte[] data, int firstByteIndex) - for direct access
getLongFrom[LE/BE](byte[] data, int firstByteOffset, int longArrayIndex) - for loops/shifted array access
etc.
I was proposing just the latter, and just for VarHandles :-) it’s not just for loops but also to bring alignment issues to the foreground. (It also it fits in with something we have been pondering about for the unsafe unaligned accessors on systems that don’t support unaligned access, such as SPARC).
What do you mean by 'just for VarHandles'? Add it between VarHandle methods? Jaroslav
On 19 May 2016, at 16:26, Jaroslav Kameník <jaroslav@kamenik.cz> wrote:
There certainly is in nio buffer sources (and may be for encoding/decoding in other areas, i am speculating as i have not looked), but for buffer sources we can actually remove much if not all of Bits.java via use of the internal Unsafe unaligned accessors.
I made some notes when I was looking at it, I am attaching it if you want look at it.
Thanks, that is helpful.
getLongFrom[LE/BE](byte[] data, int firstByteIndex) - for direct access getLongFrom[LE/BE](byte[] data, int firstByteOffset, int longArrayIndex) - for loops/shifted array access
etc.
I was proposing just the latter, and just for VarHandles :-) it’s not just for loops but also to bring alignment issues to the foreground. (It also it fits in with something we have been pondering about for the unsafe unaligned accessors on systems that don’t support unaligned access, such as SPARC).
What do you mean by 'just for VarHandles'? Add it between VarHandle methods?
I meant change the shape of the VarHandle produced by: MethodHandles.byteArrayViewVarHandle MethodHandles.byteBufferViewVarHandle The problem is feature complete is very close and it will be hard, but not impossible, to make changes afterwards. Paul.
Jaroslav
<xxs.log>
I meant change the shape of the VarHandle produced by:
MethodHandles.byteArrayViewVarHandle MethodHandles.byteBufferViewVarHandle
Aaaha:) I must say, one reason, why I'd like to have it wrapped is that VarHandle.get/set do not have fixed typed signature. Helper.longAt(arr, index) looks much better than SOME_STRANGE_CONSTANT.get(i can write here what I want and compiler says nothing:);
The problem is feature complete is very close and it will be hard, but not impossible, to make changes afterwards.
I should have started to write here earlier;). So, what will we do with it? Jaroslav
participants (2)
-
Jaroslav Kameník
-
Paul Sandoz