8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

[Aaron Grunthal]

A question from the user perspective,

If these things need to be intrinsified, does that mean we cannot expect 
the compiler to recognize the following (and similar) patterns on any 
platform and optimize them?

byte[i] = (byte)intvalue<<24
byte[i+1] = (byte)intvalue<<16
byte[i+2] = (byte)intvalue<<8
byte[i+3] = (byte)intvalue

I.e. should we always wrap byte arrays in bytebuffers if we want 
multi-byte reads?

Or is this only an issue under some limited circumstances?

Same questions for reading instead of writing.

- Aaron

On 13.03.2015 19:47, Andrew Haley wrote:
> I've tried to address all the points that have been made.
>
> I haven't changed the way the sub-words are read and written because
> the code I'm seeing is fairly nearly optimal right now and anything
> more complex runs the risk of tripping inlining limits, thus
> pessimizing performance.  We need a general solution which isn't
> optimized for special cases but is decent on average and often very
> good.  I think it's close to the best compromise we're going to get.
>
> I have changed the javadoc as requested and I have fixed the code in
> HeapByteBuffer so that it doesn't check the index twice for floating-
> point put() and get() operations.
>
> I have added a jtreg test for HeapByteBuffer which tests it pretty
> thoroughly.  It also, as a consequence, tests the underlying Unsafe
> methods.  I wasn't sure what a separate test for the Unsafe methods
> would achieve so I didn't write one.
>
> OK?
>
> http://cr.openjdk.java.net/~aph/unaligned.hotspot.6/
> http://cr.openjdk.java.net/~aph/unaligned.jdk.6/
>
> Andrew.
>